Version 6.35rc49 has been released.
...
*) tunnels - fixed performance slowdown on any other tunnel disable/enable;
...

Hi uldis

can you please advise if this specific change is to address the reports that have come in over time with PPP concentrators experiencing packet loss when individual connections were disconnected?

If so this is a great improvement and I will look to people for testing on these larger concentrators (CCR's are particularly good for this).

If not, can you please advise what types of performance slowdown this does target?

Regards
Alexander

Version 6.35rc49 has been released.

Changes since previous version:

*) dhcpv6 client - fix ia expiration and lifetime validation;
*) dhcpv6 server - acquire binding on renew if it does not exist;

I see a lot of works on dhcpv6 in recents RCs, which is a good thing.

Any timeline about adding options on the dhcpv6 client ? (like asked here : http://forum.mikrotik.com/viewtopic.php ... 81#p517695 ) ?

Thx.

Hi,

how do i enable Fast Path on my PPPOE-client? I think it will give my RB2011 more throughput.

HI,

The Dude i can not upload images, .npk files, returns "invalid file"

Best regards,

Vagner Felipe Becker

Rc49 should contain correction for the [Ticket#2016031666000222] but nothing similar is mentioned in the release notes. Is it so or not?

Any news about fixing AC mode and Intel 7260 ?

I see a lot of works on dhcpv6 in recents RCs, which is a good thing.

Any timeline about adding options on the dhcpv6 client ? (like asked here : http://forum.mikrotik.com/viewtopic.php ... 81#p517695 ) ?

Thx.

I'm also interested in this new feature.
Thanks !

in wireless-rep package,capsman could you add “bridge-mode” config support？

When installed 6.35rc49 on RB941-2nd (nonTC), got this blue error in the log:

09:52:49 script,warning DefConf: Unable to find wireless interface(s)

There are no scripts at all. What does it mean? Why there should be running any default config script while the default config was long time ago fully wiped and everything was set manually?

Any news about fixing AC mode and Intel 7260 ?

This problem is already fixed in the latest rc wireless-rep package.

Are you still seeing some problems with it?

Can I use latest current release and latest rc wireless rep package ?

Can I use latest current release and latest rc wireless rep package ?

No, you need to switch the RouterOS to Release Candidate channel and upgrade to the latest RC which currently is rc49. And then install the wireless-rep package.

Each time you upgrade, new defautl configuration file is generated, it doesn't matter if you wipe defconf or not.

So it means there is an error in the script that expects some wlan adapter but it is not present... You should correct the default script then.

How it cannot find one when there is such adapter present?

Do you have the latest ROS update and the latest firmware installed?
Did you do a reset to defaults? Did you try netinstall
Aren't these the ultimate answers for everything? 42.

Yes. This error line appears when latest rc is installed over the 6.34.4. I saw it repetitively on 4 devices. It's either the wrong defconf script or the script runs too early when drivers are not properly loaded yet. It was just to inform that it could signalised some other maybe more important problem. Otherwise I don't see any significant impact in my case so far.

Hi,
how to open then "bridge-mode" for capsman mode? thanks.

Hi,
how to open then "bridge-mode" for capsman mode? thanks.

currently it is not possible and it will not be added in the near future as it isn't just simple settings, there are lot of things needed for supporting that feature. And for the regular indoor APs you don't need this function.

6.35rc49
NV2 qos works very good, ping in low, ap control capacity of the client well. Could u add a second Wieless Protocol nv2 (ex nv2-ptp, old named nv2-ptmp) for ptp only, with some special features to improove it? Ex lower the ping and more overhead control to stable the links? It could be the option in wireless-rep, we will test it.

regards
Mateusz

6.35rc49
NV2 qos works very good, ping in low, ap control capacity of the client well. Could u add a second Wieless Protocol nv2 (ex nv2-ptp, old named nv2-ptmp) for ptp only, with some special features to improove it? Ex lower the ping and more overhead control to stable the links? It could be the option in wireless-rep, we will test it.

regards
Mateusz

"nv2-ptp", "nv2-ptmp"? I never heard of that. Only "NV2" then parameters are set for different type of link?

How did you measure the NV2 qos? Examples?

6.35rc49
NV2 qos works very good, ping in low, ap control capacity of the client well. Could u add a second Wieless Protocol nv2 (ex nv2-ptp, old named nv2-ptmp) for ptp only, with some special features to improove it? Ex lower the ping and more overhead control to stable the links? It could be the option in wireless-rep, we will test it.

regards
Mateusz

"nv2-ptp", "nv2-ptmp"? I never heard of that. Only "NV2" then parameters are set for different type of link?

How did you measure the NV2 qos? Examples?

Nv2 gives time space, and other things, it is in the code, for ptmp it is working now very well as i wrote (in auto period size one station overhead ap much before, now it isn`t). I think for ptp the code could be rewrite and aded as a second choise in menu. In lte no matter what rate and speed u have, ping is always the same, this is for me good qos. It is work for a coders, i am a customer, they must do the job to beat airmax, not me For me i rather be pleased to have 90mb and ping 0-1-2 ms on 240/240 802.11N than 130-140mb and ping 2-7-20ms, this is example. When noise apears radio should do the job and lower the speed to do 0-1-2ms, now u understand?

regards
Mateusz

v6.35rc49,

pppoe-client interface always up-down if it's doesn't get ipv6 dhcp-pd.
can it make not re-dial the pppoe if the ipv6 dhcp-pd not obtained ?

regarding options for DHCPv6-client, DHCP-PD client (and also DHCP--PD server) as it currently stands - options will be available only with RouterOS 7.x release due to technical limitations for backporting the feature.

6.35rc49
NV2 qos works very good, ping in low, ap control capacity of the client well. Could u add a second Wieless Protocol nv2 (ex nv2-ptp, old named nv2-ptmp) for ptp only, with some special features to improove it? Ex lower the ping and more overhead control to stable the links? It could be the option in wireless-rep, we will test it.

regards
Mateusz

"nv2-ptp", "nv2-ptmp"? I never heard of that. Only "NV2" then parameters are set for different type of link?

How did you measure the NV2 qos? Examples?

Nv2 gives time space, and other things, it is in the code, for ptmp it is working now very well as i wrote (in auto period size one station overhead ap much before, now it isn`t). I think for ptp the code could be rewrite and aded as a second choise in menu. In lte no matter what rate and speed u have, ping is always the same, this is for me good qos. It is work for a coders, i am a customer, they must do the job to beat airmax, not me For me i rather be pleased to have 90mb and ping 0-1-2 ms on 240/240 802.11N than 130-140mb and ping 2-7-20ms, this is example. When noise apears radio should do the job and lower the speed to do 0-1-2ms, now u understand?

regards
Mateusz

No, not a lot. Your english is a bit hard to understand.
Basically you mention that the 'auto' setting of NV2 time delay should be in two versions? One for PtMP and one for PtP?
I found 'auto' setting not always give best result anyway. We have AP with 30 clients and in changing 'auto' in 6ms we more than doubled the total throughput from AP (30 =>55Mb. Netbox5) while the ping time to client hardly changed.

I think 'auto' setting is always a compromise. If you really need to fine tune a link you have to do it manually.
But I can see your point in having 2 different default 'auto' scenarios. One for PtMP and one for PtP. That would make sense and give a better start for many of us...

To bring down a ping time by QoS is not very senseful. Your ping would be nice stable and fast, since QoS will take care of it, but your end goal is a good service level for your client's traffic. That is not ping but ordinary internet, voip, streaming TV etc. etc. If your ping is good due QoS that doesn't mean your network traffic is as good.

regarding options for DHCPv6-client, DHCP-PD client (and also DHCP--PD server) as it currently stands - options will be available only with RouterOS 7.x release due to technical limitations for backporting the feature.

Thx for the update

The famous RouterOS7.x.... I'll have to wait I guess

When using the wireless_rep- package and adding the wan1-Device to a bridge called "bridge-wan" *and* using "connect-list",
bridge-wan does not get an ip adress from dhcp. (as station)
Removing it from the bridge it recives the ip immediately.

Connection it to station without using "connect-list" works, even as bridge.

Can this be a configuration error or is this a bug?

Is it possible to add more information about connected user to CAPSMAN view with wireless-rep package?
e.g. user name being used, auto-translation of vendor part of MAC (well it´s a gimmick)

Where has gone the export compact by default with export command "only" in new terminal?????

on CapsMan channel width=10mhz not work

mANTBox 15 not work in 10mhz with manual frequency

Is it possible to add more information about connected user to CAPSMAN view with wireless-rep package?
e.g. user name being used, auto-translation of vendor part of MAC (well it´s a gimmick)

If your were to create access lists based on the OUI info in this table http://standards-oui.ieee.org/oui.txt then each registration would have manufacturer listed next to it.

on CapsMan channel width=10mhz not work

It is not, perhaps, supposed to work. My understanding is CAPsMAN currently mainly targets indoors setups with only the standard 802.11 features supported.

We have released 6.35 (current) discussion topic here http://forum.mikrotik.com/viewtopic.php?f=1&t=107307 Thanks to your feedback we have found the issue randomly causing boards to fail on upgrade during the rc testing,m this fix is included in 6.35 (current),

to successfully upgrade to 6.35 from 6.35rc29-rc49, please do a /system reboot, and then on bootup make an upgrade straight away.