We have plans to release v6.28 during this week.
Please check the latest rc version (6.28)
http://www.mikrotik.com/download/share/ ... latest.zip
http://www.mikrotik.com/download#rc

What's new in 6.28:

*) email - increase server greeting timeout to 60s;
*) lte - ZTE MF823 may loose configuration;
*) userman - update paypal root certificate;
*) timezone - updated timezone information to 2015b release;
*) cm2 - fixed capsman v2 100% CPU and other stability improvements;
*) route - using ldp could cause connected routes with
invalid interface nexthop;
*) added support for SiS 190/191 PCI Ethernet adapter;
*) made metarouter work on boards with 802.11ac support or usb LTE;
*) sstp server - allow ADH only when no certificate set;
*) make fat32 disk formatting support disks bigger than 134GiB;
*) fixed tunnels - could crash when clamp-tcp-mss was enabled;
*) added basic counters for ipv4/bridge fast path, also show status weather fast
path is active at all;
*) trafflow: - fixed crash on disable;
*) pppoe over eoip - fixed crash with large packets;
*) tilegx - fixed memory leak when queue settings are changed;
*) ar9888 - fixed crash when hw reports invalid rate;
*) console - fixed "in" operator in console;
*) console - make "/system package update print" work again.
*) tile - rare situation when CCR devices failed to auto-negotiate ethernet link (introduced in v6.25);
*) dhcpv4 client - it is now possible to unset default clientid and hostname options
*) initial RoMon (Router Management Overlay Network) support added;

As well there will be new Winbox version available,
http://www.mikrotik.com/download/share/winbox.exe

Thank you very much for your help!

Seems to be promising. Looking forward to get the final release.

Thank you for the update.

(I am posting this here because if it is a valid bug, I do not want it sneaking into 6.28, I would rather it be fixed first)

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 with a CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

What's this ???
*) initial RoMon (Router Management Overlay Network) support added;

What's this ???
*) initial RoMon (Router Management Overlay Network) support added;

Here is the Wiki page where you could see the basic information about it:
http://wiki.mikrotik.com/wiki/Manual:RoMON

I just downloaded new winbox. When I double click saved router winbox crashes.

What's this ???
*) initial RoMon (Router Management Overlay Network) support added;

Here is the Wiki page where you could see the basic information about it:
http://wiki.mikrotik.com/wiki/Manual:RoMON

Will there be a software for Linux?

If I have the device ether1-5, wlan1 is that mac is your ID?
After reboot, the default device ID is not to change?

ID usually is the RouterBoards first MAC address by default which usually is ethernet1, but you can override the ID if you want.

Thanks for the info Sergejs and Uldis and the hard work on this release!

Looking forward to testing 6.28

From my perspective, the development/testing/release process appears to have become more mature over the last couple of months. Releases are not being rushed out as they used to be; intead they seem to be more thoroughly tested. This is the right way to do it, Mikrotik team. I welcome this change and thank you for it!

A) Updated (from 6.19) n°2 RB411 to latest 6.28 (2015-04-13 16:00:53). I've experienced long time in 'export' function and I've tried to export to console screen (and not to file ..see attached image). Export stop at some point and log windows say 'timeout while waiting for program 24'. Both the RB411 upgraded have the same behaviour. Rebooted two or three times ..no changes. Roterboot firmware is latest, I've also tried to re-firmware.

B) Updated (from 6.28rc20) n°1 RB2011 to 6.28 (2015-04-13 16:00:53). System health didn't show any data and export have the same problem ad RB411. Rebooted two time ..problem disappeared.

C) Updated (from 6.27) n°1 CRS125 to 6.28 (2015-04-13 16:00:53) ..no problems.

I was told by support that the fetch/ssl bug (http://forum.mikrotik.com/viewtopic.php?f=1&t=95576) would be fixed in the next release, but the latest version (version: 6.28, build-time: Apr/13/2015 14:10:30) still doesn't download more than 4096 bytes. I really hope this is fixed before the next release because I have some maintenance to do that would be vastly easier if this would work.

Thanks,
schu

What about "hide ssid" and other wireless changes in 6.28? Nothing in changelog.
Please a detailed description ...

any resolution on this post

http://forum.mikrotik.com/viewtopic.php?f=3&t=95539

no reply from support

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 first CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

Have you ran packet captures to determine what's changing?

when metarouter will be available on CCR ?

have their been any .ac related fixes in 6.28 ?

also is there a wireless-cm2 package for 6.28 ?

edit: romon is very interesting, i like the proxy winbox functionality with romon + new winbox. I can see how this could be quite powerful, i hope its heavily developed

have their been any .ac related fixes in 6.28 ?

also is there a wireless-cm2 package for 6.28 ?

edit: romon is very interesting, i like the proxy winbox functionality with romon + new winbox. I can see how this could be quite powerful, i hope its heavily developed

+1000

Did torch get fixed? Where torch was under-reporting traffic rates? Is there a 28 version that we can test with the fix before the official release?

Nevermind, tested, and yes, fixed

It doesn't look like the builds are being updated. I just downloaded the latest and it says the build time was Apr/13/2015 14:10:30.

I really hope the ssl bug gets fixed, it's making pulling config from https impossible.

Thank you for the update.

(I am posting this here because if it is a valid bug, I do not want it sneaking into 6.28, I would rather it be fixed first)

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 with a CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

I Have the same issue, I go back to 6.20 and It works correctly. Problem appear since 6.21 at my side...

I Have the same issue, I go back to 6.20 and It works correctly. Problem appear since 6.21 at my side...

Do you have a packet capture?

Thank you for the update.

(I am posting this here because if it is a valid bug, I do not want it sneaking into 6.28, I would rather it be fixed first)

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 with a CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

I Have the same issue, I go back to 6.20 and It works correctly. Problem appear since 6.21 at my side...

CONFIRMED!!!! Moved router to 6.20 and everything works correctly. Move to 6.21 and later, problem comes back!
I tried with both SIP ALG enabled and disabled on 6.21 and later, no differences.

I should also say that the router in question is a gateway and has two firewall rules that may affect this (Although they shouldn't to my knowledge)

The first is a SRC-NAT rule that puts the entire network behind a single address that we own on BGP.

chain=srcnat action=src-nat to-addresses=X.X.X.X src-address=10.12.10.0/24 out-interface=ether1
X.X.X.X is one of our public BGP addresses
10.12.10.0/24 is the range of customers we want masqueraded behind X.X.X.X

There is a second masquerade rule at the end of the NAT table
chain=srcnat action=masquerade src-address=10.0.0.0/8 src-address-list=!DONTNAT out-interface=ether1

This catches all remaining un-natted connections and masquerades them behind the IP of the feed port.
This is used for our BGP peering and some small local telemetry etc.
The 10.12.10.0/24 network is part of the DONTNAT address list. So this should not have any effect on those addresses.

--------------------------------------------

All this to say, I did shut down all the crazy SRC-NAT rules, and use a simple masquerade rule on the outgoing interface. Same problems on 6.21+

Also, it does not explain why things work until 6.20 then stop. NAT rules don't suddenly change in versions.

--------------------------------------------
These rules are pretty much the only config this router has that would have any effect on SIP. Asides from SIP ALG (Which doesn't make any difference no matter how I set it) there is nothing touching SIP traffic.

So something had to have been introduced in 6.21 to cause this. Was there any change to SIP handling or NAT handling? changelog does not indicate this, but I cannot see what could have been done to cause this effect.

Sadly I could not make a supout file before it was too late. Test was confirmed, but I could not run further time without problems.

any problem?
internet is connected already...

Moved router to 6.20 and everything works correctly. Move to 6.21 and later, problem comes back! I tried with both SIP ALG enabled and disabled on 6.21 and later, no differences.

SIP and NAT do not work well together. We learned a long time ago never, ever, to run SIP over a NATted connection. When we stopped doing that, the cost of supporting our customers plummeted. Different NAT implementations break SIP in different ways. Given that NAT is an evil bodge in the first place, my reply to anybody who has problems using SIP over NAT is quite simply "Tough, what did you expect? Don't use NAT", I'm afraid.

There's nothing wrong with running SIP over NAT if you know what you're doing.

It's a pain in the ass, don't get me wrong on that. But it's perfectly doable.

I run hundreds of VOIP users over different NATs from different providers over different technologies. ALL work flawlessly... Except when I put a Mikrotik in the middle running 6.21+ firmware.

This is why I'm so puzzled over this, and why I think it's a bug.

This isn't a question of normal NAT stupidities like one way audio, registrations that die after a certain time, too many registrations from one IP... It's a question of registrations COMPLETELY not working anymore. Backing firmware down one version, and everything goes back to normal.

DSL, Cable, WISP, 3G, LTE, etc...
Cisco, Juniper, Linksys, Dlink, TPlink, Moto, Cambium, Ubnt, etc...
All flawless, except this one jump from MT 6.20 to 6.21+.

It's not a perfect example, but it's pretty obvious something isn't as it should be.

EDIT - I should have also mentioned, it's not a handful of customers that drop off, it's ALL of them behind the MT. So it's a complete break, not partial.

EDIT - I should have also mentioned, it's not a handful of customers that drop off, it's ALL of them behind the MT. So it's a complete break, not partial.

That must be somehow dependent on the configuration of your Mikrotik and/or SIP client and/or server in use. Just tried Zoiper registering to localphone.com and making a call through Mikrotik box running 6.27 without a single problem. This Mikrotik box has NAT and stateful firewall configured, SIP ALG enabled.

EDIT - I should have also mentioned, it's not a handful of customers that drop off, it's ALL of them behind the MT. So it's a complete break, not partial.

That must be somehow dependent on the configuration of your Mikrotik and/or SIP client and/or server in use.

Well, you have to admit that it IS strange that the problem only seems to occur with a change in RouterOS versions, so at the very least this DOES suggest a difference at SOME level in how RouterOS is doing the NATting compared to before...

jdog, to clarify, you are saying that certain SIP clients cannot register AT ALL after upgrading to 6.21+, or do they work for a certain amount of time and THEN everything breaks, but if you reboot the router, they will start working again for a bit before breaking again?

If they don't work at all, have you tried doing a packet capture of what is going on between the SIP client and the SIP registrar/server, from both sides of the MikroTik (LAN and WAN)? If not, and if you can set up a test account on your SIP server that you aren't worried about exposing the credentials to (because you can delete the account right away after running the capture), I would be happy to take a look at any captures you make. It may be possible to figure out where the breakdown is occurring.

-- Nathan

There's nothing wrong with running SIP over NAT if you know what you're doing.

It's a pain in the ass, don't get me wrong on that. But it's perfectly doable.

I run hundreds of VOIP users over different NATs from different providers over different technologies. ALL work flawlessly... Except when I put a Mikrotik in the middle running 6.21+ firmware.

This is why I'm so puzzled over this, and why I think it's a bug.

This isn't a question of normal NAT stupidities like one way audio, registrations that die after a certain time, too many registrations from one IP... It's a question of registrations COMPLETELY not working anymore. Backing firmware down one version, and everything goes back to normal.

DSL, Cable, WISP, 3G, LTE, etc...
Cisco, Juniper, Linksys, Dlink, TPlink, Moto, Cambium, Ubnt, etc...
All flawless, except this one jump from MT 6.20 to 6.21+.

It's not a perfect example, but it's pretty obvious something isn't as it should be.

EDIT - I should have also mentioned, it's not a handful of customers that drop off, it's ALL of them behind the MT. So it's a complete break, not partial.

After each upgrade and especially upgrade/downgrade cycle, always check your configuration: firewall rules, ip settings, etc............

I am trying latest rc version and FASTPATH status shows in rb2011 that fastpath is off. Despite that is enabled in ip settings and all conditions for fastpath are met (disabled connections tracking, queues, mangle..).
What is problem?

Sorry, we do not have data to share as we did not capture any but we had issues with our clients running SIP applications too.
Our PBX works normal for clients not served from Mikrotik router.
But client served from Mikrotik router after upgrade to 6.25 they do not have outbound any more. What we found is if you change the ATA to UDP instead of TCP, everything works again.
Sorry we were busy and happy to find an easy fix but we never spent time to analyze the real issue.

Sorry I didn't have time to do full packet captures during the times it was not working. Just too much, too fast, and too critical to leave it not running.

To confirm the above question, it's a *complete* break. So nothing registers at all. It's not as if it partially registers, or registers for a while and then drops off, it's a perfect zero registration.

The other thing that is even more strange, is it only seems to be affecting certain hardware (Regardless of VOIP service, which is even more strange). As I said, Polycom does not seem to have any problems, but Cisco ATAs are a complete loss, as well as a couple other models (I didn't make a list, those were the only two I noticed and remembered). All of the VOIP units are as close to "basic" programming as can be. No custom ports or "non-standard" settings (Sorry I know that's a broad definition).

The thing to consider as well, this is the only situation that has managed to break this functionality. The VOIP providers that use the Cisco ATAs (With the same config as the ones we lost) all operate fine on various other ISPs behind NAT, even behind double NAT, all with different routers and equipment in the middle. In fact the only time we have been ABLE to kill the connections was with this upgrade. Before it didn't really matter what we did, it still worked perfectly. I used to think these things were magic for how well they dealt with bad NAT situations. This is one of the main reasons why I feel something just doesn't seem right with the MT firmware. We are using the ATAs etc in hundreds and hundreds of different setups and this is the only one that has ever caused a loss of registration.

I will try another upgrade test and hopefully packet capture, but it will involve a very late night change, and I am not sure if I will be able to do this in the short term. If anyone else has seen similar issues, please give some details if you can, and maybe we can help localize what module could be causing this. (Or what config issue we need to be aware of).

Thanks for all the help everyone.

Do not turn on RoMON on productive routers. This can lead to hangs.
On my RB850Gx2 RoMON does not work, and one core hangs after RoMON turning off.
And you have to reboot the router.

We have plans to release v6.28 during this week.

Really this week?

We have plans to release v6.28 during this week.

Really this week?

Better late than with bugs!

I hope it goes to the end of next week, or later, if it means the bugs are found and fixed. This last one with hanging CPU worries me.

I really don't like new features added along with bug fixes. Ensure the bugs are dead before adding things. Most importantly though, don't add new features in RC chain. Don't add them in BETA chain, add only in Alpha.

We have plans to release v6.28 during this week.

Really this week?

Better late than with bugs!

Last time - "late and with bugs".

We have plans to release v6.28 during this week.

Really this week?

Better late than with bugs!

+1

Last time - "late and with bugs".

We have plans to release v6.28 during this week.

Really this week?

Better late than with bugs!

Better stop opening threads without having an certain release date or a certain list with bugs that are really fixed without introducing another ones, this approach is kind a childish and imature

Better stop opening threads without having an certain release date or a certain list with bugs that are really fixed without introducing another ones, this approach is kind a childish and imature

Well the testing on this release have been going on for some weeks now,so i whouldnt call it imature and there is probaly a good reason why it hvaent been relased. As other have sayd its bether they delay it if there is known bug then release a faulty version.
Besides none is foreceing you to update if the version you have installed is working and there is no known security holes.

I Have problem with PPPOe Session Duplicate.

1. Show Session PPPOE Duplicates
2. I can't Delete the session.
3. I have MPLS/VPLS/VLAN/PPPOE
4.Can Bridge VPLS with the VLAN in the AP
5. CPE is Authentication with PPPOE

v6.28 (CCR103612G4S)

/interface pppoe-server server
add disabled=no interface=vpls-1003sector1-res \
keepalive-timeout=15 max-mru=1460 max-mtu=1460 one-session-per-host=yes \
service-name="pppoe-vpls-1003sector1-res"

...but Cisco ATAs are a complete loss...

I would love to run some tests myself, and although we don't use Cisco TAs in the wild/in production, I do happen to have an older Cisco/Linksys PAP2T sitting in a closet somewhere. Is this a model that is confirmed to be broken for you?

I will try another upgrade test and hopefully packet capture, but it will involve a very late night change, and I am not sure if I will be able to do this in the short term.

I'm confused about the "late night changes" thing. If it is a 100% reproducible problem, rather than using a live customer as a test subject, are you not able to take one of these Cisco TAs + a RouterBoard off the shelf, and run similar tests in a lab environment?

-- Nathan

ITT: People moaning about VoIP with no interest in helping resolve it.

I use CCR's at every one of my sites, and all of my MD's have Rb2011's at their homes. We use a ShoreTel VoIP system and we do not have any issues, even with the MD's using the phones at home. I think most VoIP issues are caused by lack of a good clear understanding of the SIP & RTSP protocols, and not understanding how to correctly implement them.

I use CCR's at every one of my sites, and all of my MD's have Rb2011's at their homes. We use a ShoreTel VoIP system and we do not have any issues, even with the MD's using the phones at home. I think most VoIP issues are caused by lack of a good clear understanding of the SIP & RTSP protocols, and not understanding how to correctly implement them.

I agree that proper understanding is paramount, and we also run our own VoIP service (homegrown/Asterisk-based) that we, too, do not have any NAT-related problems with, and we use MikroTik everywhere...in front of the Asterisk server, as CPEs for customers, etc.

But if jdog also had no problems until right after 6.21, and the only thing that changed when he upgraded to 6.21 (if he is to be believed) is the software -- configuration of the ATAs and routers remained otherwise IDENTICAL and downgrading to 6.20 fixes the problem for him -- then clearly *SOMETHING* changed in RouterOS.

Now, whatever that something is, it might be that it is something that *should* have changed. Maybe there was a NAT bug that MikroTik fixed and that they should have fixed, and with the way that jdog has his network configured or the way that his VoIP service provider has their side configured, his set-up should not have been working in the first place, and it was simply by a quirk and stroke of luck that it was working (a side-effect of an otherwise improper implementation of something somewhere in RouterOS). The basic fact is that we don't know who to point the finger at or who is at fault until somebody runs some controlled tests and takes some @#$%@%^ing packet captures.

I keep saying that I'm willing to do this, assuming I can get my hands on equipment that will fail in the same way once similarly configured...all I need are some precise details about exactly what equipment I should be using and how to configure it in order to match jdog's setup as closely as possible in order to reproduce the problem.

Even though I am suffering NO problems myself with any of our voice customers who have SIP clients behind MikroTiks running >= 6.21, it is in my interest to see us arrive at a definitive answer to the question of whether or not this is a legitimate RouterOS bug, because I don't want to be bit by it in the future if it is.

-- Nathan

have their been any .ac related fixes in 6.28 ?

also is there a wireless-cm2 package for 6.28 ?

edit: romon is very interesting, i like the proxy winbox functionality with romon + new winbox. I can see how this could be quite powerful, i hope its heavily developed

+1000

+10000

Sorry I didn't have time to do full packet captures during the times it was not working. Just too much, too fast, and too critical to leave it not running.

To confirm the above question, it's a *complete* break. So nothing registers at all. It's not as if it partially registers, or registers for a while and then drops off, it's a perfect zero registration.

The other thing that is even more strange, is it only seems to be affecting certain hardware (Regardless of VOIP service, which is even more strange). As I said, Polycom does not seem to have any problems, but Cisco ATAs are a complete loss, as well as a couple other models (I didn't make a list, those were the only two I noticed and remembered). All of the VOIP units are as close to "basic" programming as can be. No custom ports or "non-standard" settings (Sorry I know that's a broad definition).

The thing to consider as well, this is the only situation that has managed to break this functionality. The VOIP providers that use the Cisco ATAs (With the same config as the ones we lost) all operate fine on various other ISPs behind NAT, even behind double NAT, all with different routers and equipment in the middle. In fact the only time we have been ABLE to kill the connections was with this upgrade. Before it didn't really matter what we did, it still worked perfectly. I used to think these things were magic for how well they dealt with bad NAT situations. This is one of the main reasons why I feel something just doesn't seem right with the MT firmware. We are using the ATAs etc in hundreds and hundreds of different setups and this is the only one that has ever caused a loss of registration.

I will try another upgrade test and hopefully packet capture, but it will involve a very late night change, and I am not sure if I will be able to do this in the short term. If anyone else has seen similar issues, please give some details if you can, and maybe we can help localize what module could be causing this. (Or what config issue we need to be aware of).

Thanks for all the help everyone.

For me it is the same.

I using SNOM without any issue on this case, but with Siemens Gigaset DECT, I have the issue, cannot register anymore. Ping is possible.
I'm not using nat. there are several remote site connected via EOIP to a central site with private addressing, even with no NAT I have the issue.
6.20 Ok
6.20+(remote & central), after few days Gigaset device cannot register anymore, or call originating from Siemens is without sounds. Like in NAT/RTP issue, but here no NAT usage for data going to EOIP to central site, but NAT is used for Internet.

I just downloaded new winbox. When I double click saved router winbox crashes.

I had the same problem, you need to clear your winbox cache manually from your user folder. Make sure you export your saved sessions because when you manually clear your cache all saved sessions will be deleted too

Hi guys, sorry for late reply, been busy.

marrold, I'd like to help resolve it as much as I possibly can, however I'm operating in production, so I can't just decide to change things and pull readings etc whenever I want. Production world doesn't work like that.

And to follow up before someone says "you shouldn't do this in production anyway!"... I agree, and we did bench test it as much as was possible. We don't have a spare voip setup that matches this exact layout.

This router is doing OSPF, BGP, etc and is acting as a main gateway on a fiber line. There are too many variables to reproduce, and I have nowhere that I can put it where it is in an exact same configuration. We have gotten it as closely as possible to this situation on the bench, but have not been able to go further. (Hence why the cutover went perfectly, despite this one single issue) My goal this week is to try and get further testing done, and hopefully some *&(*&@ packet captures.

To confirm some of the questions:
- The Cisco ATAs are SPA122 and SPA112. Some are behind a PPPoE connection directly to this router, others are sitting on IP/Ethernet links (Passing through radio bridges). Network configs don't seem to matter. (This makes me feel that this is not an MTU issue either, as it was one of my theories.)

- The config between the upgrades on this router are absolutely identical export/imports. I can flip the firmware between 6.20 and 6.21+ like a switch and it's the only bug/problem that we encounter.

In the end this could be a possible VOIP config issue. But I'm seriously doubting it from what I'm seeing. Perhaps it's an incompatibility with the Cisco units as well, but this seems to occur across all Cisco firmware versions. I confirmed 4 different versions running on ATAs, including the newest version. I also don't believe this is a Cisco issue or a voip config issue as these ATAs run on every other provider, with almost every crazy configuration possible, without any issues. This is the first time I've seen anything actually "break" them.

As I said, I'm going to try and get some packet captures, but it's going to take time.
I just wish I could get a better idea of what could be causing the trigger for this problem between those firmware versions. From what I see, there is nothing in the changelogs that *should* have an effect on this. But something obviously is. Maybe it's not a bug, but it's still something that I need to identify.

With the delay of 6.28 (I prefer as others better updates not fast updates) Will any of the fixes address a universal problem we are seeing and I have seen other comment on with NV2 TCP throughput.

Even with 6.28 RC20 we see the same problem On an NV2 circuit if every interface along the path is not negotiated at 1gig then there is a Dramatic tcp speed drop. From 100Meg in our case to 10 Meg TCP. We see the UDP is still doing fine but tcp is all but halted.

However, this does not accuse with Nstream.

I for one would really rather see the 802.11ac and NV2 bugs fixed and stabilized prior to any new features being released.

With the delay of 6.28 (I prefer as others better updates not fast updates) Will any of the fixes address a universal problem we are seeing and I have seen other comment on with NV2 TCP throughput.

Even with 6.28 RC20 we see the same problem On an NV2 circuit if every interface along the path is not negotiated at 1gig then there is a Dramatic tcp speed drop. From 100Meg in our case to 10 Meg TCP. We see the UDP is still doing fine but tcp is all but halted.

However, this does not accuse with Nstream.

I for one would really rather see the 802.11ac and NV2 bugs fixed and stabilized prior to any new features being released.

Talked to responsible people at the MUM in Prague. There is no solution for nv2 regarding this problem in the near future. He promised some work to stabilize nstreme for ptp. Time frame was 3-6 months.

As we cant live with this situation (I am bored talking to speedtesters every day) we replace ptp with other gear which does not show this problems.

@jdog
Have you tried disabling SIP direct media in firewall settings ?

Yes I did try that as well (Both on and off configurations).

In theory that should only affect the media flow though, and not registrations correct?
My issue is with initial registrations not even happening.

Well the testing on this release have been going on for some weeks now,so i whouldnt call it imature and there is probaly a good reason why it hvaent been relased. As other have sayd its bether they delay it if there is known bug then release a faulty version.
Besides none is foreceing you to update if the version you have installed is working and there is no known security holes.

Nope, you didn't understand. Don't promise or make announcements about things that you're not sure about, this it's not pro

I have a ccr1016-12g , basic configuration ppoe client + routing, but ccr1016-12g stops routing after 10 or 20min aprox, not scan and find it through Winbox, ping no respond, I have to turn off and turn back to work and connected to CCR, nothing is logged, no errors are shown and it otherwise appears to be happy and healthy, where is the problem? , , back to my crs, because this has problems.

SIP helper in RouterOS has some features that other way may be needed to be disabled. Or, if your configuration is running configuration aware of NAT you should be able to disable the helper altogether.

Points of interest to you are these settings:
sip-timeout - TTL of SIP connection, defaults to 1 hour
sip-direct-media - to redirect RTP media streams when NAT is used.

You can try do set to connection-tracking default timeout value and disable direct-media.

.. just an idea:
- some complain about problems concerning PPPoE (duplicating, ..)
- the problems to SIP do not seem related to NAT (some do not use NAT)

Makes me wonder if all those who complain about problems on SIP are using PPPoE (in effect in the changelog PPPoE has been changed)

Dont say "this week" because there is a new week every 7 days!

Yes I did try that as well (Both on and off configurations).

In theory that should only affect the media flow though, and not registrations correct?
My issue is with initial registrations not even happening.

I had similar issue when I replaced my Linux based gateways with CCR and it helped. It's magic.

With the delay of 6.28 (I prefer as others better updates not fast updates) Will any of the fixes address a universal problem we are seeing and I have seen other comment on with NV2 TCP throughput.

Even with 6.28 RC20 we see the same problem On an NV2 circuit if every interface along the path is not negotiated at 1gig then there is a Dramatic tcp speed drop. From 100Meg in our case to 10 Meg TCP. We see the UDP is still doing fine but tcp is all but halted.

However, this does not accuse with Nstream.

I for one would really rather see the 802.11ac and NV2 bugs fixed and stabilized prior to any new features being released.

Talked to responsible people at the MUM in Prague. There is no solution for nv2 regarding this problem in the near future. He promised some work to stabilize nstreme for ptp. Time frame was 3-6 months.

As we cant live with this situation (I am bored talking to speedtesters every day) we replace ptp with other gear which does not show this problems.

So this is really an important failure that needs to be mentioned!
In the last weeks/months I am puzzled why I get more and more clients with speed issues (yes, it looks they don't do nothing else than speedtests and bombard the results to me.... ) and indeed I see link with poor throughputs that were fine months ago.
I blame it on interferences but in some cases nothing is to be found that really worries me...

So now the final word is out (regular member could have filtered that in the forum) that when a NV2 running network is used and units are more and more going to be replaced by gig-able devices you basically break your network down!

You guys are basically saying the backhauls should made nstreme instead of NV2? That would help the issue until you have all units in a link from user to border router replaced by Gigabit units...

Question 1: Nstream only on the backhauls would help? AP-CPE networks can be left in NV2?
Question 2: Does is make a difference where in the whole route fm internet gateway towards end user units are gig or fast ethernet?

Reading this post makes me both happy and very disappointed.

Happy because it finally give me the reason for all my sorrows lately.....
Sad because it seems instead of upgrading my network I am basically downgrading it and MT "doesn't foresee a quick solution??"

This could really be my last push towards a new hardware provider (no, that is not going to be ubnt!) for the whole of my network. Only need to find the money!
I think I look for a bottle and call it a day.....

Forgot to ask; Would setting the gigabit ports to 100Mb manual not solve the issue?
Is a gigabit port set to 100/100 not acting as fastethernet port? Or is there still an issue then?

Forgot to ask; Would setting the gigabit ports to 100Mb manual not solve the issue?
Is a gigabit port set to 100/100 not acting as fastethernet port? Or is there still an issue then?

I have found that the only solution is with negotiation. The problem with that is that when links or auto negotiated and with the problem of poor our negotiation currently plaguing previous firmware. One minute my network will be at one gig and the next it's at 100 meg making the problem worse

Forgot to ask; Would setting the gigabit ports to 100Mb manual not solve the issue?
Is a gigabit port set to 100/100 not acting as fastethernet port? Or is there still an issue then?

I have found that the only solution is with negotiation. The problem with that is that when links or auto negotiated and with the problem of poor our negotiation currently plaguing previous firmware. One minute my network will be at one gig and the next it's at 100 meg making the problem worse

I don't understand what you mean? Can you explain?

Sorry was trying to post from my cell phone.

I have found that the only fix it to have the ports Auto Neg to 1 gig. The problem is I have ports that will flap from 1 Gig to 100 MEg. IN that case the problem is much worse as the customer is getting the speed they purchased but then the speed in general goes down to 10 Meg because my port flapped to 100 Meg.

sip-timeout - TTL of SIP connection, defaults to 1 hour

Hi,
I'm running 6.28 and would like to configure the sip-timeout value.
But can't find it anywhere.

Have gone in via IP/firewall/service ports
and clicked on the sip line.

Can see SIP Direct Media but not sip-timeout.
Went in through both the web interface and Winbox.

It was the same with version 6.23, sip-timeout not there either.
Help, thanks.

Thank you for the update.

(I am posting this here because if it is a valid bug, I do not want it sneaking into 6.28, I would rather it be fixed first)

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 with a CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

I have the sameexact issues. Registration not holding.
I have checked with my VOIP carrier, he told me that the sip request comes from internal IP 192.168.0.xx on the ATA that are not working (cisco spa 112 with latest firmware).
No other config changes occured. For sure it can be a ROS issue.

Thank you for the update.

(I am posting this here because if it is a valid bug, I do not want it sneaking into 6.28, I would rather it be fixed first)

I have a small bug I encountered with a CCR1036 and I am unsure if this is a config issue.

I replaced a RB-1100AHx2 with a CCR1036.
RB-1100AHx2 was running 5.25 and CCR1036 was running 6.27
(Unfortunately this leaves a huge gap in firmware issues, however I do have other RBs running more recent 6.x firmware that don't have this problem, so I believe it's "recent")

Essentially VOIP/SIP stops working correctly. Registrations to not occur/hold.
There are no SIP/VOIP related firewall rules, and config is export/import identical.
Running the two RBs side by side, RB-1100AHx2, works perfectly. CCR1036, registrations break.

To make matters worse, it only occurs with certain VOIP hardware.
Polycom phones = good.
Cisco phones/ATA = bad

Checking the config on the Cisco, they all work perfectly with other setups and other ISPs, only when passing through the Mikrotik they stop working.

I have tried with SIP ALG enabled, and disabled, no differences.

Are there, or have there been any known issues for SIP/VOIP in recent firmwares?

I have the sameexact issues. Registration not holding.
I have checked with my VOIP carrier, he told me that the sip request comes from internal IP 192.168.0.xx on the ATA that are not working (cisco spa 112 with latest firmware).
No other config changes occured. For sure it can be a ROS issue.

Similar for me, but at random. And indeed only on Cisco spa 112 or 122.
To correct we need to erase all connection rules in both client CPE as the border gateway (because trackin remembers) and we need to power cycle both client wifi router and spa or when spa is in front, the SIP adapter.
After that a unit will register newly with my SIP/VOIP provider under its proper public IP.

If anywhere anything goes wrong, like my main border routers swap, two SIP lines on one public IP, or we take an adapter back form a client to install somewhere else (so a new register add is made at provider) things go wrong.
We have a CCR as border router.
And indeed the VOIP provider tells me the unit gets registred under a local 192.168.xxx.xxx address which can only be the client's wifi router. This should not be happening since the clients network gets srce natted into a Client<===>CPE network, than in a CPE<===>Borderrouter local network and only than into a public IP.

We actually blamed the VOIP provider for their crappy server, but now it looks like.........?

With "connection rules" I meaned to say "registrations in the conn. tracker"

Anyone know what issue "route - using ldp could cause connected routes with invalid interface nexthop" refers to? Any link to any post on the forum discussing this exact fault?

I think I may have found a key to this issue...

If you are "masquerading" your network behind an address using a src-nat action, everything breaks.
If you are "masquerading" your network behind an address using a masquerade action, everything works.

We normally use a src-nat action to masquerade sections of our network behind static IPs that we have for BGP.

As an example we split each /25 of our internal network, into one static IP. We do this using src-nat actions.
This rule is where things break or stop working.

The moment I change the src-nat rule to a masquerade action (It doesn't preserve the same outgoing IP as the src-nat rule, but same concept) everything works.

I think there may possibly be a problem with the connection tracking mechanism in the src-nat rule vs the masquerade rule. Certainly there must be something different between the two.

MT? Ideas?

MT... Ideas?