You dont need any wifi packagge on your CCR anymore to have a running >wifi< capsman. All included in the routeros package. You most probably won’t lose your config.
As always
export terse file=<filename> show-sensitive
will be your friend if configuration would be lost. You can always restore relevant parts from there.
Indeed! Will try it during the next maintenance window
Understood. Thanks!
Thanks!
EDIT
I Did some more testing that made the below questions irrelevant.
Apparently SW Vlans have ALWAYS bled through when bridge ports are disabled (ran through a few versions of ROS testing)
RSTP did stop them in the end - I just had to be more patient… just odd that whenever i’ve done these build before i have generally dropped the bridge ports - and never had a vlan bleed through a disabled bridge port - that I noticed.
Just though i’d leave this in place for transparency - but it appears that my recollecion of how things “worked” was incorrect… and although maybe undesired function - appears to just be the way it is for now.
ORIGINAL POST
Unsure if anyone else is having any issues with switch vlanning
General Configs for QCA8337 switches have been roughly switch vlans with bridge ports. Bridge Vlans disable hardware offload - so this has been the best way to use vlans while keeping wire speed
Usually - when I disable a bridge port in this scenarion - all traffice across the switch stopps to this port.
Just building a site with 7.16.1 - and have found that during build - when I completed config of a wireless link - that once it links and loops (as expected), if I disable one of the looped bridge ports - the loop continues on what appears to be the vlans.
Previously, disabling the bridge port would stop All traffic to that port - stopping the loop
Long term - this will not be an issue - as these wireless links will not be on the same switch - but it does appear there is an issues - and it makes it more diffidcult to recover from a loop condition out in the field.
This was done on a RB960-PGS-PB
Also to Note - in the case of the OmnitikAC-PoE - that I was also building before - disabling the WLAN port in the bridge DID have the desired affect… probably due to the fact that the wlan was not in the switch. Also - IIRC - disabling the ethernet bridge ports had the desired effect here too.
has anyone else noted any issues with SW vlans in this F/W… do we know if there has been any chnages to the older chips not mentioned?
Any Info appreciated.
I have enabled dhcpv6 client via terminal and now every command that I do inside ipv6/dhcp-client hangs or times out. Notice the “#error exporting “/ipv6/dhcp-client” (timeout)” in the middle of the text:
[xxx@MikroTik8] /ipv6> export
2024-11-23 00:53:51 by RouterOS 7.16.1
software id = 3GZX-TBTL
model = CRS112-8P-4S
serial number = F14F0EFCA324
#error exporting “/ipv6/dhcp-client” (timeout)
/ipv6 nd
set [ find default=yes ] disabled=yes mtu=1492 ra-preference=high retransmit-interval=3s
/ipv6 settings
set accept-redirects=no accept-router-advertisements=yes forward=no max-neighbor-entries=8096
[xxx@MikroTik8] /ipv6>
I don’t see the DHCPv6 client record in WinBox but when I try to add one, it complains “dhcp-client on that interface already exists”.
I even tried to restart the router multiple times.
How can I fix this? How can I remove the dhcpv6 client that is not being shown anywhere?
There’s been some kind of confusing situation. It doesn’t make any sense. I have two 4011s with firmware 7.16.1 that were fine a week ago. Today I noticed that DHCPv6 client on both devices stopped working normally. I have not made any changes to the settings. Everything “really” broke on its own.
/ipv6 address
# address pool error: pool not found: ipv6-triolan (4)
add eui-64=yes from-pool=ipv6-triolan interface=bridge1
#error exporting "/ipv6/dhcp-client" (timeout)
In the backup from the previous weekend, these lines looked like this:
/ipv6 address add address=::2ec8:1bff:feae:493d eui-64=yes from-pool=ipv6-triolan interface=bridge1
/ipv6 dhcp-client add add-default-route=yes interface=sfp-sfpplus1 pool-name=ipv6-triolan rapid-commit=no request=prefix script=":if (\$\"pd-valid\" = 1) do={\r\
\n /ipv6 firewall address-list remove [find list=allowed]\r\
\n :delay 1s\r\
\n /ipv6 firewall address-list add address=\$\"pd-prefix\" comment=\"!!! Check YOUR pool from ISP\" list=allowed\r\
\n /ipv6 firewall address-list add address=fe80::/16 list=allowed\r\
\n /ipv6 firewall address-list add address=ff02::/16 comment=multicast list=allowed\r\
\n :delay 1s\r\
\n} \r\
\n" use-interface-duid=yes use-peer-dns=no
Did devices reboot in between by any chance?
Yes, both devices rebooted during this period.
By the way, noticed a similar problem on another 4011. This is the third one.
I had a similar problem on version 7.16. Completely different location, but also on 4011. The solution was to downgrade ROS to 7.15.3, disable and delete all IPv6 settings, upgrade ROS to 7.16 and configure IPv6 again. I tried the same steps (ROS downgrade, etc.) on these three routers. However, it did not work. I cannot re-configure IPv6.
I would like to point out, that I have only observed a similar problem with 4011. The routers are located in neighboring houses in a cottage village. In the building, where the village security is located - hAP ac3, in the building next to it - CCR1016-12G. And no problems with IPv6.
And one more question. I have routers, that do not use IPv6 at all. Why do such devices assign an internal IPv6 address to IPIP tunnels? The use of the protocol is disabled, the addresses are invalid.
hello,
firstly, i found that dhcp-snooping feature on crs3xx does not work on this version, i will open separate ticket for this.
CORRECTION: It did not work as the other switch that connected from has not been set to trusted yet.
secondly, i wonder if dhcp vendor-class can give an option of static-only for the address-pool of choosen value.
third, i have hap-ax3 here. work good for ethernet and wireless as expected with vlan-1; but when i create virtual ssid with other vlan, it won’t work. datapath with vlan tagged also does not work.
thank you
P
While using RouterOS version 7.16.*, I encountered the following issue:
I need to resolve the domain name test.ab.lan locally, while forwarding other *.lan domain names to a third-party DNS server. I implemented the following code:
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.1.1 name=test.ab.lan type=A
add forward-to=192.168.2.1 regexp="(^|\\.)lan\$" type=FWD
This code worked perfectly in version 7.15.* and earlier. However, in version 7.16.*, an issue arises.
When other machines query test.ab.lan from this device, it seems that the FWD rule is executed first instead of responding with the address 192.168.1.1 as specified.
I find this behavior counterintuitive and unreasonable.
SUP-172504
What’s new in 7.16.2 (2024-Nov-26 14:09):
*) certificate - do not download CRL if there is not enough free RAM;
*) certificate - fixed handling of capsman-cap certificates (introduced in v7.16);
*) dhcpv4-server/relay - added additional error messages for DHCP servers and relays;
*) dns - fixed lookup order for static DNS entries (introduced in v7.16.1);
*) ethernet - improved linking after reboot for hAP ax lite devices (“/system routerboard upgrade” required);
*) gps - changed default GPS antenna setting for LtAP mini with internal LTE/GPS combo antenna;
*) leds - fixed bogus argument for “leds” property (introduced in v7.16);
*) leds - fixed PoE-in LEDs for CRS318-1Fi-15Fr-2S device;
*) modem - KNOT BG77 modem, improved handling of modem unexpected restarts;
*) route - fixed possible issue with inactive routes after reboot (introduced in v7.16);
*) routerboot - improved stability for IPQ8072 and IPQ6010 when flash-boot is used (“/system routerboard upgrade” required);
*) dns - fixed lookup order for static DNS entries (introduced in v7.16.1);
I did not know that there is an documented lookup order at all? Any details? Is this the problem reported here: https://forum.mikrotik.com/viewtopic.php?p=1111498#p1111473 ?
It’s time..
7.16.2 → long-term
7.17 → stable
Won’t happen. It would be ridiculous to introduce security measures in stable branch while keeping “loose device-mode” in a long-term branch for another long period of time.
Personal view:
the fact 7.16.2 is being made, makes me think/hope it might take a bit longer before 7.17 becomes stable since all bug fixes here, are also available in 7.17 chain.
And that might be a good thing so more issues can be ironed out for 7.17.
Hi,
And in v7.16.X there are still problems with ipsec policies, resolved in v7.17rc1.
Surely you are already working on the new v7.18 beta.
Greetings
Hi,
I did an upgrade on my capsman (CHR) and caps (cap AX and hAP ax2) from 7.16.1 to 7.16.2.
In the logs of the caps I can see this message:
“no suitable CAPsMAN”
Anybody else seeing the same issue?