No BTH option in IP/CLOUD

wifiwave2 - use CAPsMAN's "datapath.vlan-id" on CAP for bridge port "pvid"; << Thank you!

wifiwave2 - use CAPsMAN's "datapath.vlan-id" on CAP for bridge port "pvid"; << Thank you!

Yeah, does this do what I think it does???

Yeah, does this do what I think it does???

Yes it does:
[attachment=0]Screenshot_20231007-004343.png[/attachment
💪😁

Yes it does:

Screenshot_20231007-004343.png[/attachment 💪😁 [/quote] Does it also add the interface to the VLANs tab in the bridge as tagged? My VLANs for WiFi work fine regardless of the PVID setting on the port but they don't work at all unless the WiFi interface is added to the VLAN as "tagged". This happens automatically on legacy CAPsMAN. [/quote] Yes, it does it also. It´s now the same behaviour as with the "old" CAPsMAN for AC devices. [attachment=0]hc_159.jpg

Does it also add the interface to the VLANs tab in the bridge as tagged? My VLANs for WiFi work fine regardless of the PVID setting on the port but they don't work at all unless the WiFi interface is added to the VLAN as "tagged". This happens automatically on legacy CAPsMAN.

Does it also add the interface to the VLANs tab in the bridge as tagged? My VLANs for WiFi work fine regardless of the PVID setting on the port but they don't work at all unless the WiFi interface is added to the VLAN as "tagged". This happens automatically on legacy CAPsMAN.

Yes, it does it also. It´s now the same behaviour as with the "old" CAPsMAN for AC devices.
hc_159.jpg

*) wifiwave2 - use CAPsMAN's "datapath.vlan-id" on CAP for bridge port "pvid";
*) bridge - fixed fast-path forwarding with HW offloaded vlan-filtering (introduced in v7.11);
*) bridge - fixed vlan-filtering stability with HW and non-HW offloaded ports (introduced in v7.10);
*) bridge - improved vlan-filtering bridge stability with CAPsMAN (introduced in v7.11);

802.11n/ac interfaces do not support this type of VLAN tagging under the wifiwave2 package, but they can be configured as VLAN access ports in bridge settings.

*) interface - added "macvlan" interface support;

*) pimsm - improved system stability;

Does it also add the interface to the VLANs tab in the bridge as tagged? My VLANs for WiFi work fine regardless of the PVID setting on the port but they don't work at all unless the WiFi interface is added to the VLAN as "tagged". This happens automatically on legacy CAPsMAN.

Yes, it does it also. It´s now the same behaviour as with the "old" CAPsMAN for AC devices.

• Does any of this apply if I have "slaves static" applied?
• Does 7.12rc1 have to be on both the cap and the capsman device?

Yes, it does it also. It´s now the same behaviour as with the "old" CAPsMAN for AC devices.

OK so now the real questions.

• Does any of this apply if I have "slaves static" applied?
• Does 7.12rc1 have to be on both the cap and the capsman device?

As you can probably guess, none of this dynamic stuff mentioned in 7.12rc1 is working for me at all. That is, I see no change in behaviour.

I don´t know what you mean with "slaves static", but to enable the dynamic add of virtual wifi interfaces to the bridge it´s nessesary to enable the "Slaves Datapath" in the CAP menu on the CAP itself.

This is the trick, without this setting nothing happens in the bridge or the VLANs on the CAP.

P.S. I don't suppose if you know whether wifi1 and wifi2 should also be dynamically added to the bridge or if it only applies to slave interfaces? I tested it just now and it only seems to apply to the slaves. That is, I need to manually add wifi1 and wifi2 to the bridge with PVID 1.

P.S. I don't suppose if you know whether wifi1 and wifi2 should also be dynamically added to the bridge or if it only applies to slave interfaces? I tested it just now and it only seems to apply to the slaves. That is, I need to manually add wifi1 and wifi2 to the bridge with PVID 1.

They are added dynamically to the bridge:
hc_661.jpg

@Kaldek, I moved all my Cap AX to be managed by CapsMAN a few weeks ago and have no issues. Running 7.11.2 right now and all interfaces, both main and slaves are added to bridge and correct VLAN, even if there is a bug that add PVID 1 right now, fixed in 7.12, everything works great and I LOVE that roaming works!! Now I can finally move around while having a teams call.
Have a look at the VLAN example here: https://help.mikrotik.com/docs/display/ ... ionexample:
Works great for as as long as you do not miss configuring slaves-datapath as I did first!

They are added dynamically to the bridge

/interface/wifiwave2/set wifi1 configuration.manager=capsman .mode=ap datapath.bridge=bridge
/interface/wifiwave2/set wifi2 configuration.manager=capsman .mode=ap datapath.bridge=bridge

/interface bridge port add bridge=bridge interface=wifi1
/interface bridge port add bridge=bridge interface=wifi2

Did anyone testing 7.12rc1in a wifiwave2 device (hAP-ax3 in my case) notice some kind of stickiness to 2,4GHz frecuency? Previously roaming to 5GHz works flawlesly in 7.11, but now it seems some devices are kind of lazy to roam, even when they are quite close to the AP (2m away, literaly), unless you remove that from registration list. 5GHz is operating in 5180MHz, so DFS radar issue is discarded.

They are added dynamically to the bridge

Can I ask you for an export of your Datapath settings for the wifi1 and wifi2 interfaces? There's something you're doing which makes the dynamic assignment work, and there's something I'm doing which is stopping it from working.

Update: The only way I can get the wifi1 and wifi2 interfaces dynamically into the bridge is to put the follow command on the cAP ax itself:

Code: Select all

/interface/wifiwave2/set wifi1 configuration.manager=capsman .mode=ap datapath.bridge=bridge
/interface/wifiwave2/set wifi2 configuration.manager=capsman .mode=ap datapath.bridge=bridge

If I don't manually add the "datapath.bridge=bridge" to the cAP itself, the interface will not by dynamically added to the bridge ports.

I fail to see how this is any more helpful or "better" than the following commands, which is how I'm doing it currently:

Code: Select all

/interface bridge port add bridge=bridge interface=wifi1
/interface bridge port add bridge=bridge interface=wifi2

It's still two lines of commands, entered on the cAP. Nothing at the CAPsMAN side seems to be able to implement this.

/interface wifiwave2 datapath
add bridge=bridge1-Hausnetz disabled=no name=Hausnetz
/interface bridge port
add bridge=bridge1-Hausnetz interface=ether1 trusted=yes
add bridge=bridge1-Hausnetz interface=ether2
/interface bridge vlan
add bridge=bridge1-Hausnetz tagged=ether1,ether2 vlan-ids=99
add bridge=bridge1-Hausnetz tagged=ether1,ether2 vlan-ids=98
/interface wifiwave2 cap
set certificate=request discovery-interfaces=bridge1-Hausnetz enabled=yes lock-to-caps-man=yes slaves-datapath=Hausnetz

I have a x86 box(with 2 intel i211) with Mikrtok v7(L4) installed. The tx and rx irqs are assigned to 1 cpu on 7.12rc, as a result, the CPU usage is not even distributed to all 4 cores.

Yes, you´re right, you have to configure the "Datapath" on the CAP itself in the Wifiwave2 menu.
But this ist the way like MT mentioned it has to be. It was the answer even in one of my support tickets from the MT-support (SUP-115988)
I totally agree that you have to configure much more locally on the CAPs as it was before in the "old" CAPsMAN for AC devices and I´m not totally happy with this. But it works.

I have a x86 box(with 2 intel i211) with Mikrtok v7(L4) installed. The tx and rx irqs are assigned to 1 cpu on 7.12rc, as a result, the CPU usage is not even distributed to all 4 cores.

Can anyone else confirm that problem witx x86 machines and RouterOS 7.x ?

Did anyone testing 7.12rc1in a wifiwave2 device (hAP-ax3 in my case) notice some kind of stickiness to 2,4GHz frecuency? Previously roaming to 5GHz works flawlesly in 7.11, but now it seems some devices are kind of lazy to roam, even when they are quite close to the AP (2m away, literaly), unless you remove that from registration list. 5GHz is operating in 5180MHz, so DFS radar issue is discarded.

I've found that some intel AX cards get weird preference for 2.4ghz. I really need to capture the 802.11k and 802.11v data and see if there is anything in there which is confusing clients.

I've found that some intel AX cards get weird preference for 2.4ghz. I really need to capture the 802.11k and 802.11v data and see if there is anything in there which is confusing clients.

Thanks a lot for confirming this Kaldek. Same behavior here.

Kind regards!

Yes, you´re right, you have to configure the "Datapath" on the CAP itself in the Wifiwave2 menu.

/interface wifiwave2 datapath add bridge=bridge name="Local Bridge"
/interface wifiwave2 set [ find default-name=wifi1 ] configuration.manager=capsman .mode=ap datapath="Local Bridge"
/interface wifiwave2 set [ find default-name=wifi2 ] configuration.manager=capsman .mode=ap datapath="Local Bridge"
/interface wifiwave2 cap set discovery-interfaces=bridge enabled=yes slaves-datapath="Local Bridge" slaves-static=no

It is very very quiet recently - in both beta and stable threads.
Not sure - it might be a good sign?
Maybe even a v7 long-term on the way?

Why do you have a VLAN interface under the Bridge?
In my setup they all report as tagged into the Bridge which is what I want. Then the bridge has a trunk port to the switches to manage the VLAN so it finds it's way back to the firewall/router to be processed.
I can be wrong here but if they where untagged in that case they would end up on the VLAN that you set on the bridge, which in my case is my management VLAN, everything else runs as tagged.

I can be wrong here ...

Just trialed 7.12rc to try and get WAVE2-Capsman-Controller ( on a RB5009 ) to properly set VLAN datapath on a cap unit ( in my case a cAP ax ) set as a cap with the manager set to capsman.
..
Anyhow the crux of the 7.12rc1 issue is that the allocated VLAN for each wireless-radio is being put into "Current Tagged" and should be going into "Current untagged" in the bridge/vlan..

/interface bridge
add name=bridge vlan-filtering=yes pvid=1000
/interface wifiwave2 datapath add bridge=bridge name="Local Bridge" vlan-id=1000
/interface wifiwave2 set [ find default-name=wifi1 ] configuration.manager=capsman .mode=ap datapath="Local Bridge"
/interface wifiwave2 set [ find default-name=wifi2 ] configuration.manager=capsman .mode=ap datapath="Local Bridge"
/interface wifiwave2 cap set discovery-interfaces=bridge enabled=yes slaves-datapath="Local Bridge" slaves-static=no

These wifi wave2's capsmans is not yet as fully functional as the legacy CAPsMAN, and I'm just pointing out where this vlan/datapath/ tagging function needs to be fixed.. My example I'm using is not in the production environment. I have 10 new cAP AX's on the shelf, and waiting to install once this gets fixed.

These wifi wave2's capsmans is not yet as fully functional as the legacy CAPsMAN, and I'm just pointing out where this vlan/datapath/ tagging function needs to be fixed.. My example I'm using is not in the production environment. I have 10 new cAP AX's on the shelf, and waiting to install once this gets fixed.

What I do not get is how this is backward thinking as I'm using the recommended config from Mikrotik.

I think it's time you uploaded your configs mate.

HERE IS A VIDEO SHOWING THE ISSUE
https://www.youtube.com/watch?v=PLI-1Qm1Lp4

HERE IS THE CONTROLLER

Code: Select all

/interface wifiwave2 channel
add band=5ghz-ac disabled=no frequency=5200 name=5GHZ_CHANNEL40_20_AC width=20mhz
add band=2ghz-n disabled=no frequency=2437 name=2GHZ_CHANNEL6_20_N width=20mhz
/interface wifiwave2 datapath
add disabled=no name=datapath10 vlan-id=10
add disabled=no name=datapath20 vlan-id=20
add disabled=no name=datapath30 vlan-id=30
/interface wifiwave2 security
add authentication-types=wpa2-psk disabled=no name=VLAN10_GUEST_INTERNET
add authentication-types=wpa2-psk disabled=no name=VLAN20_CORP_INTERNET
add authentication-types=wpa2-psk disabled=no name=VLAN30_INTERNAL_SYSTEMS
/interface wifiwave2 configuration
add channel=5GHZ_CHANNEL40_20_AC country=Australia datapath=datapath10 disabled=no mode=ap name=5GHZ_VLAN10_GUEST_INTERNET security=VLAN10_GUEST_INTERNET ssid=GUESTINTERNET
add datapath=datapath30 disabled=no name=5GHZ_VLAN30_INTERNALSYSTEMS security=VLAN30_INTERNAL_SYSTEMS ssid=INTERNALSYSTEMS
add datapath=datapath20 disabled=no name=5GHZ_VLAN20_CORP_INTERNET security=VLAN20_CORP_INTERNET ssid=CORPINTERNET
add channel=2GHZ_CHANNEL6_20_N country=Australia datapath=datapath10 disabled=no mode=ap name=2.4GHZ_VLAN10_GUEST_INTERNET security=VLAN10_GUEST_INTERNET ssid=GUESTINTERNET
add datapath=datapath20 disabled=no name=2.4GHZ_VLAN20_CORP_INTERNET security=VLAN20_CORP_INTERNET ssid=CORPINTERNET
add datapath=datapath30 disabled=no name=2.4GHz_VLAN30_INTERNALSYSTEMS security=VLAN30_INTERNAL_SYSTEMS ssid=INTERNALSYSTEMS
/interface wifiwave2
add channel=2GHZ_CHANNEL6_20_N channel.frequency=2437 configuration=2.4GHZ_VLAN10_GUEST_INTERNET configuration.mode=ap disabled=no name=2.4GHZ_MASTER_VLAN10 radio-mac=48:A9:8A:CC:77:E5
add channel.frequency=2437 configuration=2.4GHZ_VLAN20_CORP_INTERNET configuration.mode=ap disabled=no mac-address=4A:A9:8A:CC:77:E5 master-interface=2.4GHZ_MASTER_VLAN10 name=2.4GHZ_SLAVE_VLAN20
add channel.frequency=2437 configuration=2.4GHz_VLAN30_INTERNALSYSTEMS configuration.mode=ap disabled=no mac-address=4A:A9:8A:CC:77:E6 master-interface=2.4GHZ_MASTER_VLAN10 name=2.4GHZ_SLAVE_VLAN30
add channel=5GHZ_CHANNEL40_20_AC channel.frequency=5200 configuration=5GHZ_VLAN10_GUEST_INTERNET configuration.mode=ap datapath=datapath10 disabled=no name=5GHZ_MASTER_VLAN10 radio-mac=48:A9:8A:CC:77:E4 security=VLAN10_GUEST_INTERNET
add configuration=5GHZ_VLAN20_CORP_INTERNET configuration.mode=ap disabled=no mac-address=4A:A9:8A:CC:77:E4 master-interface=5GHZ_MASTER_VLAN10 name=5GHZ_SLAVE_VLAN20
add configuration=5GHZ_VLAN30_INTERNALSYSTEMS configuration.mode=ap disabled=no mac-address=4A:A9:8A:CC:77:E7 master-interface=5GHZ_MASTER_VLAN10 name=5GHZ_SLAVE_VLAN30
/interface wifiwave2 capsman
set enabled=yes interfaces=vlan100 package-path="" require-peer-certificate=no upgrade-policy=none

HERE IS THE EXAMPLE CAP AX UNIT

Code: Select all

/interface bridge
add admin-mac=AA:BB:CC:DD:EE:FF auto-mac=no frame-types=admit-only-vlan-tagged name=bridge1 vlan-filtering=yes
/interface vlan
add interface=bridge1 name=vlan100-MANAGEMENT vlan-id=100
/interface wifiwave2 datapath
add bridge=bridge1 comment=defconf disabled=no name=capdp
/interface wifiwave2
# managed by CAPsMAN
# mode: AP, SSID: GUESTINTERNET, channel: 5200/ac
set [ find default-name=wifi1 ] configuration.manager=capsman .mode=ap datapath=capdp disabled=no name=wifi1-5GHZ
# managed by CAPsMAN
# mode: AP, SSID: GUESTINTERNET, channel: 2437/n
set [ find default-name=wifi2 ] configuration.manager=capsman .mode=ap datapath=capdp disabled=no name=wifi2-2.4GHz
/interface bridge port
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=all
/interface bridge vlan
add bridge=bridge1 tagged=ether1,bridge1 vlan-ids=100
add bridge=bridge1 tagged=ether1 vlan-ids=10
add bridge=bridge1 tagged=ether1 vlan-ids=20
add bridge=bridge1 tagged=ether1 vlan-ids=30
/interface wifiwave2 cap
set discovery-interfaces=vlan100-MANAGEMENT enabled=yes slaves-datapath=capdp
/ip address
add address=192.168.100.2/24 interface=vlan100-MANAGEMENT network=192.168.100.0
/ip cloud
set update-time=no
/ip dhcp-client
add interface=bridge1
/system identity
set name=ExampleUnit1
/system note
set show-at-login=no
/tool romon
set enabled=yes

On iOS 17 devices, established IKE2 peers will disconnect after 24 minutes of being connected.
The disconnect happened after rekeying sent by the responder and then rejected by the initiator.
ROS = 7.11.2, 7.12rc1
Responder PFS= none

Code: Select all

 14:13:28 ipsec --->IPSEC: -> ike2 request, exchange: CREATE_CHILD_SA:44 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec --->IPSEC: payload seen: ENC (292 bytes)
 14:13:28 ipsec --->IPSEC: processing payload: ENC
 14:13:28 ipsec,debug --->IPSEC: => iv (size 0x10)
 14:13:28 ipsec --->IPSEC: payload seen: NOTIFY (12 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: SA (92 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: NONCE (20 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: KE (72 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: TS_I (24 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: TS_R (24 bytes)
 14:13:28 ipsec --->IPSEC: create child: respond
 14:13:28 ipsec --->IPSEC: processing payloads: NOTIFY
 14:13:28 ipsec --->IPSEC:   notify: REKEY_SA
 14:13:28 ipsec --->IPSEC: rekeying child SA 0xd1dabae
 14:13:28 ipsec --->IPSEC: peer wants tunnel mode
 14:13:28 ipsec --->IPSEC: processing payload: TS_R
 14:13:28 ipsec --->IPSEC: 0.0.0.0/0
 14:13:28 ipsec --->IPSEC: processing payload: TS_I
 14:13:28 ipsec --->IPSEC: 172.18.2.200
 14:13:28 ipsec --->IPSEC: checking: 0.0.0.0/0 <=> 172.18.2.200
 14:13:28 ipsec --->IPSEC: processing payload: SA
 14:13:28 ipsec --->IPSEC: IKE Protocol: ESP
 14:13:28 ipsec --->IPSEC:  proposal #1
 14:13:28 ipsec --->IPSEC:   enc: aes256-cbc
 14:13:28 ipsec --->IPSEC:   auth: sha256
 14:13:28 ipsec --->IPSEC:   dh: ecp256
 14:13:28 ipsec --->IPSEC:  proposal #2
 14:13:28 ipsec --->IPSEC:   enc: aes256-cbc
 14:13:28 ipsec --->IPSEC:   auth: sha256
 14:13:28 ipsec --->IPSEC: matched proposal:
 14:13:28 ipsec --->IPSEC:  proposal #2
 14:13:28 ipsec --->IPSEC:   enc: aes256-cbc
 14:13:28 ipsec --->IPSEC:   auth: sha256
 14:13:28 ipsec --->IPSEC: processing payload: NONCE
 14:13:28 ipsec --->IPSEC: create child: finish
 14:13:28 ipsec --->IPSEC: adding payload: NONCE
 14:13:28 ipsec,debug --->IPSEC: => (size 0x1c)
 14:13:28 ipsec --->IPSEC: initiator selector: 172.18.2.200 
 14:13:28 ipsec --->IPSEC: adding payload: TS_I
 14:13:28 ipsec,debug --->IPSEC: => (size 0x18)
 14:13:28 ipsec --->IPSEC: responder selector: 0.0.0.0/0 
 14:13:28 ipsec --->IPSEC: adding payload: TS_R
 14:13:28 ipsec,debug --->IPSEC: => (size 0x18)
 14:13:28 ipsec --->IPSEC: adding payload: SA
 14:13:28 ipsec,debug --->IPSEC: => (size 0x2c)
 14:13:28 ipsec --->IPSEC: <- ike2 reply, exchange: CREATE_CHILD_SA:44 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec,debug --->IPSEC: ===== sending 256 bytes from responder-ip[4500] to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: 1 times of 260 bytes message will be sent to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: => child keymat (size 0x80)
 14:13:28 ipsec --->IPSEC: IPsec-SA established: initiator-ip[4500]->responder-ip[4500] spi=0xb39e1af
 14:13:28 ipsec,debug --->IPSEC: ===== received 80 bytes from initiator-ip[4500] to responder-ip[4500]
 14:13:28 ipsec --->IPSEC: -> ike2 request, exchange: INFORMATIONAL:45 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec --->IPSEC: payload seen: ENC (52 bytes)
 14:13:28 ipsec --->IPSEC: processing payload: ENC
 14:13:28 ipsec,debug --->IPSEC: => iv (size 0x10)
 14:13:28 ipsec,debug --->IPSEC: decrypted packet
 14:13:28 ipsec --->IPSEC: payload seen: DELETE (12 bytes)
 14:13:28 ipsec --->IPSEC: respond: info
 14:13:28 ipsec --->IPSEC: processing payloads: NOTIFY (none found)
 14:13:28 ipsec --->IPSEC: processing payloads: DELETE
 14:13:28 ipsec --->IPSEC: delete ESP SA
 14:13:28 ipsec --->IPSEC: delete spi: 0xd1dabae
 14:13:28 ipsec --->IPSEC: IPsec-SA established: responder-ip[4500]->initiator-ip[4500] spi=0xde365b1
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: initiator-ip[4500]->responder-ip[4500] spi=0xe8c243e
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: responder-ip[4500]->initiator-ip[4500] spi=0xd1dabae
 14:13:28 ipsec,debug --->IPSEC: sending empty reply
 14:13:28 ipsec --->IPSEC: <- ike2 reply, exchange: INFORMATIONAL:45 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec,debug --->IPSEC: ===== sending 160 bytes from responder-ip[4500] to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: 1 times of 164 bytes message will be sent to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: ===== received 80 bytes from initiator-ip[4500] to responder-ip[4500]
 14:13:28 ipsec --->IPSEC: -> ike2 request, exchange: INFORMATIONAL:46 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec --->IPSEC: payload seen: ENC (52 bytes)
 14:13:28 ipsec --->IPSEC: processing payload: ENC
 14:13:28 ipsec,debug --->IPSEC: => iv (size 0x10)
 14:13:28 ipsec,debug --->IPSEC: decrypted packet
 14:13:28 ipsec --->IPSEC: payload seen: DELETE (8 bytes)
 14:13:28 ipsec --->IPSEC: respond: info
 14:13:28 ipsec --->IPSEC: processing payloads: NOTIFY (none found)
 14:13:28 ipsec --->IPSEC: processing payloads: DELETE
 14:13:28 ipsec --->IPSEC: delete IKE SA
 14:13:28 ipsec --->IPSEC: <- ike2 reply, exchange: INFORMATIONAL:46 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec,debug --->IPSEC: ===== sending 128 bytes from responder-ip[4500] to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: 1 times of 132 bytes message will be sent to initiator-ip[4500]
 14:13:28 ipsec,info killing ike2 SA: IKE2 responder-ip[4500]-initiator-ip[4500] spi:016061474fafcdab:c6d3a55dca1d4567
 14:13:28 ipsec,info --->IPSEC: killing ike2 SA: IKE2 responder-ip[4500]-initiator-ip[4500] spi:016061474fafcdab:c6d3a55dca1d4567
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: initiator-ip[4500]->responder-ip[4500] spi=0xb39e1af
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: responder-ip[4500]->initiator-ip[4500] spi=0xde365b1
 14:13:28 ipsec --->IPSEC: removing generated policy
 14:13:28 ipsec --->IPSEC: KA remove: responder-ip[4500]->initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: KA tree dump: responder-ip[4500]->initiator-ip[4500] (in_use=1)
 14:13:28 ipsec,debug --->IPSEC: KA removing this one...
 14:13:28 ipsec,info releasing address 172.18.2.200
 14:13:28 ipsec,info --->IPSEC: releasing address 172.18.2.200

result code

What's new in 7.12rc1 (2023-Oct-05 08:46):

Changes in this release:

!) ethernet - changed "advertise" and "speed" arguments, and removed "half-duplex" setting under "/interface ethernet" menu;
!) sfp - convert configuration to support new link modes for SFP and QSFP type of interfaces;
*) bfd - fixed sessions when setting VRF;
*) bfd - improved system stability;
*) console - improved system stability;
*) email - rename "address" property to "server";
*) flash - show more accurate "total-hdd-space" resource property;
*) gps - expose GPS port for Quectel EM12-G (vendor-id="0x2c7c", device-id="0x0512");
*) ike1 - fixed invalid key length on phase1 negotiation;
*) interface - added "macvlan" interface support;
*) l3hw - prioritize local IP addresses over the respective /32 and /128 routes;
*) leds - fixed "wireless-status" and "wireless-signal-strength" for wireless interfaces (introduced in v7.12beta7);
*) netinstall-cli - updated configuration option description;
*) pimsm - improved system stability;
*) poe-out - improved "auto" mode for devices with single PoE-out port;
*) qsfp - improved auto link detection for AOC cables;
*) route - added "single-process" configuration setting, enabled by default on devices with 64MB or less RAM memory;
*) route - added "suppress-hw-offload" setting for IPv6 routes;
*) sfp - added 5Gbps rate for SFP+ interface on 98DX224S, 98DX226S, and 98DX3236 switch chips;
*) sfp - fixed failed auto-negotiation for RB5009 devices (introduced in v7.12beta3);
*) sfp - improved system stability with certain modules for 98DX224S, 98DX226S, 98DX3236, 98DX8216 and 98DX8208 switch chips;
*) tftp - fixed empty file name matching;
*) webfig - fixed interface addition (introduced in v7.12beta7);
*) wifiwave2 - added an alternative QoS priority assignment mechanism based on IP DSCP;
*) wifiwave2 - added station-bridge interface mode;
*) wifiwave2 - implemented an option to transmit IP multicast packets as unicasts;
*) wifiwave2 - use CAPsMAN's "datapath.vlan-id" on CAP for bridge port "pvid";
*) winbox - added "Addresses" property under "Routing/BFD/Configuration" menu;
*) winbox - added "BUS" property for USB Power Reset button for LtAP-2HnD and CCR1072;
*) winbox - added "USB" button under "System/RouterBOARD" menu for LtAP-2HnD;
*) winbox - added Enable/Disable button under "Routing/RIP/Static Neighbors" menu;
*) winbox - added missing properties under "WifiWave2" menu;
*) winbox - do not show "F" flag for disabled entries under "IP/Routes" menu;
*) winbox - fixed "Do" property under "Routing/Filters/Select Rule" menu;
*) winbox - fixed "Range" property under "Routing/Filters/Num Set" menu;
*) winbox - fixed "Switch" menu for CCR2004-16G-2S+;
*) winbox - improved support for certain properties under "WifiWave2/Interworking Profiles" menu;
*) winbox - show "unknown" value for "FS" property under "System/Disks" menu if the data is not available;
*) wireguard - added "auto" and "none" parameter for "private-key" and "presharde-key" parameters;
*) wireguard - allow to specify client settings under peer menu which will be included in configuration file and QR code;

Other changes since v7.11:

!) health - removed "temperature" health entry from boards, where it was the same as "sfp-temperature";
*) api - fixed fetching objects with warning option from REST API;
*) bgp - fixed "atomic-aggregate" always set in output;
*) bgp - fixed "input.filter-chain" argument selection in VPN configuration;
*) bgp - fixed local and remote port settings for BGP connections;
*) bgp - fixed typos and missing spaces in log messages;
*) bgp - implemented IGP metric sending in BGP messages;
*) bgp - improved logging;
*) bgp - increase "hold-time" limit to 65000;
*) bluetooth - added basic support for connecting to BLE peripheral devices;
*) bluetooth - use "g" units when decoding MikroTik beacon acceleration on peripheral devices menu;
*) bridge - fixed fast-path forwarding with HW offloaded vlan-filtering (introduced in v7.11);
*) bridge - fixed untagged VLAN entry disable;
*) bridge - fixed vlan-filtering stability with HW and non-HW offloaded ports (introduced in v7.10);
*) bridge - improved system stability;
*) bridge - improved vlan-filtering bridge stability with CAPsMAN (introduced in v7.11);
*) calea - improved system stability when trying to add rules without the CALEA package;
*) certificate - allow to get and maintain Let's Encrypt certificate in IPv6 environment;
*) certificate - allow to remove issued certificates when CRL is not used;
*) certificate - fixed "subject-alt-name" duplicating itself when SCEP is used;
*) certificate - fixed certificate auto renewal via SCEP;
*) certificate - improved certificate validation logging error messages;
*) certificate - log CRL HTTP errors under the "error" logging topic;
*) chr - iavf updated driver to 4.9.1 version;
*) chr - increased OVA default RAM amount from 160MB to 256MB;
*) console - added ":jobname" command;
*) console - added "as-string" and "as-string-value" properties for "get" command;
*) console - added "terminal/ask" command;
*) console - added "transform" property for ":convert" command;
*) console - export required properties with default values;
*) console - fixed scheduler "on-event" script highlighting when editing;
*) console - improved ":totime" and ":tonum" commands and added ":tonsec" command for time value manipulation;
*) console - improved multi-argument property parsing into array;
*) console - improved randomness for ":rndstr" and ":rndnum" commands;
*) console - improved stability and responsiveness;
*) console - improved stability when editing long scripts;
*) console - improved stability when using "special-login";
*) console - improved system stability through RoMON session;
*) console - improved system stability when using autocomplete;
*) console - restrict permissions to "read,write,reboot,ftp,romon,test" for scripts executed by DHCP, Hotspot, PPP and Traffic-Monitor services;
*) console - show full date and time in scheduler "next-run" property;
*) dhcp - fixed DHCP server "authoritative" and "delay-threshold" settings (introduced in v7.12beta3);
*) dhcp - fixed DHCP server and relay related response delays;
*) ethernet - added "supported" and "sfp-supported" values for "monitor" command;
*) firewall - added "ein-snat" and "ein-dnat" connection NAT state matchers for filter and mangle rules;
*) ike1 - log an error when non-RSA keys are being used;
*) ike2 - improved rekey collision handling;
*) iot - fixed an issue where applying a script to GPIO pin caused GPIO to stop working;
*) iot - fixed behavior where GPIO output state would change on boot;
*) ipsec - fixed Diffie-Hellman public value encoding size;
*) ipsec - fixed IPSec policy when using modp3072;
*) ipsec - fixed minor typo in logs;
*) ipsec - reduce disk writes when started without active configuration;
*) ipv6 - fixed IPv6 RA delay time from 5s to 500ms according to RFC;
*) ipv6 - send RA and RA deprecate messages out three times instead of just once;
*) l3hw - fixed IPv6 route suppression;
*) l3hw - improved system stability during IPv6 route offloading;
*) led - fixed "interface-status" configuration for virtual interfaces;
*) leds - added "dark-mode" functionality for RBwAPG-5HacD2HnD;
*) leds - added "wireless-status" and "wireless-signal-strength" configuration types for wifiwave2 interfaces;
*) log - improved logging for user actions;
*) lora - added LNS protocol support;
*) lte - added at-chat support and increased wait time on modem at-chat for Dell DW5821e, DW5821e-eSIM, DW5829e and DW5829e-eSIM;
*) lte - added SINR reporting for FG621-EA modem;
*) lte - changed R11e-LTE ARP behavior to NoArp;
*) lte - fixed 5G data-class reporting for Chateau 5G;
*) lte - fixed APN authentification in multi APN setup for R11e-LTE6;
*) lte - fixed IPv6 prefix for MBIM modems in multi-apn setup when IPv6 APN used as not first APN;
*) lte - fixed RSSI for FG621-EA modem to show the correct value;
*) lte - fixed Sierra modem detection for modems with vendor-specific USB descriptors;
*) lte - fixed Sierra modem initialization;
*) lte - fixed startup race condition when SIM card is in "up" slot for LtAP mini;
*) lte - fixed sub-interface auto-removal in multiple APN setups;
*) lte - show correct data class when connected to 5G SA network;
*) lte - use more compact logging messages;
*) modbus - added additional security settings for Modbus TCP;
*) mpls - added option to match and set MPLS EXP with bridge and mangle rules;
*) mpls - fixed "propagate-ttl=no" setting;
*) mpls - improved FastPath next-hop selection hash algorithm;
*) mqtt - added on-message feature for subscribed topics;
*) mqtt - added parallel-scripts-limit parameter to set maximum allowed number of scripts executed at the same time;
*) mqtt - added wildcard topic subscription support;
*) netinstall - added option to discard branding package;
*) netinstall - display package filename in GUI Description column if package description is not specified;
*) netinstall-cli - added empty configuration option "-e";
*) netinstall-cli - added option to discard branding package;
*) netinstall-cli - allow ".rsc" script filenames;
*) netinstall-cli - prioritise interface option over address option;
*) netwatch - decreased "thr-tcp-conn-time" maximum limit to 30 seconds;
*) ospf - fixed adding ECMP routes;
*) ospf - fixed BFD on virtual-link with configured VRF;
*) ospf - fixed OSPFv3 not working with NSSA areas;
*) ospf - fixed parsing of opaque LSAs used by TE;
*) ospf - fixed translated NSSA routes not showing in backbone;
*) ovpn - added "tls-auth" option support for imported .ovpn profiles;
*) ovpn - improved system stability;
*) poe-out - driver optimization for AF/AT controlled boards;
*) poe-out - fixed rare CRS328 poe-out menu and poe-out port config loss after reboot;
*) port - add support for Huawei MS237h-517;
*) port - expose NMEA/DIAG ports for Dell DW5821e and DW5821e-eSIM;
*) qsfp - added 50Gbps rate support for QSFP28 interfaces;
*) qsfp - fixed sub-interface EEPROM monitor data output (introduced in v7.12beta3);
*) qsfp - improved auto link detection for 100G CWDM4 modules and AOC cables (introduced in v7.12beta3);
*) qsfp - use sub-interface configuration for establishing link (for 40Gbps and 100Gbps links, all sub-interfaces must be enabled);
*) quickset - fixed "LAN" interface list members if configuration does not contain bridge;
*) rip - added BFD support;
*) rip - fixed session not working in VRF;
*) route - fixed gateway after link restart;
*) route - removed deprecated "received-from" property;
*) route - reverse community "delete" and "filter" command behavior;
*) routerboard - added "reset-button" support for RB800, RB1100 and RB1100AHx2 devices;
*) sfp - fixed 25Gbps link with FEC91 (introduced in v7.12beta7);
*) sfp - fixed missing "rx-power" monitor with certain modules (introduced in v7.10);
*) sfp - improved interface stability for SFP and QSFP types of interfaces;
*) snmp - changed "mtxrGaugeValue" type to integer;
*) ssh - added support for user ed25519 public keys;
*) ssh - allow to specify key owner on import;
*) ssh - fixed SSH tunnel performance (introduced in v7.10);
*) ssh - improved connection stability when pasting large chunks of text into console;
*) supout - added interface list members section;
*) supout - added LLDP power to supout.rif;
*) supout - fixed BFD section;
*) switch - fixed packet forwarding between Ethernet ports for CRS354 switches (introduced in v7.12beta7);
*) switch - improved resource allocation for 98DX224S, 98DX226S, and 98DX3236 switch chips;
*) switch - improved switch chip stability for CCR2004-16g-2s+ devices;
*) system - improved system stability when MD5 checksums are used;
*) tile - improved system stability when using queues;
*) traffic-generator - added "priority" property for "inject" command;
*) traffic-generator - fixed traffic-generator on CHR and x86;
*) usb - added support for RTL8153 USB ethernet on ARM, ARM64 and x86;
*) vrf - limit maximum VRFs to 1024;
*) vxlan - improved system stability for Tile devices;
*) webfig - fixed "Days" property configuration change under "IP/Firewall" menu;
*) webfig - fixed timezone for interface "Last Link Down/Up Time";
*) webfig - improved Webfig performance and responsiveness;
*) webfig - try to re-establish connection after disconnect;
*) wifiwave2 - added comment property for registration-table;
*) wifiwave2 - correctly add interface to specified "datapath.interface-list";
*) wifiwave2 - do not show default "l2mtu" on compact export;
*) wifiwave2 - enable changing interface MTU and L2MTU;
*) wifiwave2 - fixed malformed Interworking packet elements;
*) wifiwave2 - fixed PTK renewal for interfaces in station mode;
*) wifiwave2 - fixed re-connection failures for 802.11ax interfaces in station mode;
*) wifiwave2 - fixed sniffer command not receiving any QoS null function frames when using 802.11ax radios;
*) wifiwave2 - fixed untagged VLAN 1 entry when using "vlan-id" setting together with vlan-filtering bridge;
*) wifiwave2 - fixed warning on CAP devices when radar detected;
*) wifiwave2 - improved compliance with regulatory requirements;
*) wifiwave2 - limit L2MTU to 1560 until a fix is available for a bug causing interfaces to fail transmitting larger frames than that;
*) wifiwave2 - list APs with a higher maximum data rate as more preferable roaming candidates;
*) wifiwave2 - log more information regarding authentication failures;
*) wifiwave2 - make 4-way handshake procedure more robust when acting as supplicant (client);
*) winbox - added "Comment" under "Routing/BFD/Configuration" menu;
*) winbox - added "g" flag under "IPv6/Routes" menu;
*) winbox - added "Host Key Type" setting under "IP/SSH" menu;
*) winbox - added "Key Owner" setting under "System/User/SSH Keys" and "System/User/SSH Private Keys" menus;
*) winbox - added "Name Format" property under "WifiWave2/Provisioning" menu;
*) winbox - added "Remote Min Tx" parameter under "Routing/BFD/Session" menu;
*) winbox - added "Startup Delay" setting under "Tools/Netwatch" menu;
*) winbox - added "Use BFD" setting under "Routing/RIP/Interface-Template" menu;
*) winbox - added MQTT subscription menu;
*) winbox - allow to change port numbers for SCTP, DCCP, and UDP-LITE protocols under "IP/Firewall" menus;
*) winbox - allow to set multiple addresses and added IPv6 support under "Interface/VETH" menu;
*) winbox - allow to specify server as DNS name under "Tools/Email" menu;
*) winbox - changed "MBR Partition Table" checkbox to unchecked by default under "System/Disks/Format-Drive" menu;
*) winbox - fixed "Address" property under "WifiWave2/Remote-CAP" menu;
*) winbox - fixed "Group Key Update" maximum value under "WifiWave2/Security" menu;
*) winbox - fixed entry numbering and ordering under "WifiWave2/Provisioning" menu;
*) winbox - fixed minor typos;
*) winbox - rename "DSCP" setting to "DSCP (+ECN)" under "Tools/Traffic-Generator/Packet-Templates" menu;
*) winbox - rename "Name" setting to "List" under "IP,IPv6/Firewall/Address-List" menu;
*) winbox - rename "Password" button to "Change Now" under "System/Password" menu;
*) wireguard - added "wg-export" and "wg-import" functionality (CLI only);
*) wireguard - request public or private key to be specified in order to create peer;
*) wireless - added more "radius-mac-format" options (CLI only);
*) wireless - fixed malformed Interworking packet elements;
*) www - fixed allowed address setting for REST API users;
*) www - fixed fragmented POST data for SCEP service;
*) x86 - added support for Mellanox ConnectX-6 Dx NIC;
*) x86 - i40e updated driver to 2.23.17 version;
*) x86 - igb updated driver to 5.14.16 version;
*) x86 - igbvf updated driver from in-tree Linux kernel;
*) x86 - igc updated driver to 5.10.194 version;
*) x86 - ixgbe updated driver to 5.19.6 version;
*) x86 - Realtek r8169 updated driver;
*) x86 - updated latest available pci.ids;

In the following link (which I use in my scripts) the correct content of the Changelog is not updated, it only reports the previous version 7.12rc1

file content code

7.12rc2 1697467828\n

In the following link (which I use in my scripts) the correct content of the Changelog is not updated, it only reports the previous version 7.12rc1

Use the correct URLs...
viewtopic.php?t=200103#p1030161

https://upgrade.mikrotik.com//routeros/NEWEST7.testing

file content code

7.12rc2 1697467828\n

example code

{
:local sysname    [/system identity get name]
:local latestVer  7.12rc2
:local changeLog  ([/tool fetch "https://upgrade.mikrotik.com/routeros/$ ... /CHANGELOG" output=user as-value] -> "data")
/tool e-mail send to="admin@email.com" subject="[Router $sysname] New testing version!" body="New: $latestVer\n\n$changeLog"
}

Sorry about that. Changelogs are fixed now.

HERE IS A VIDEO SHOWING THE ISSUE
https://www.youtube.com/watch?v=PLI-1Qm1Lp4

HERE IS A VIDEO SHOWING THE ISSUE
https://www.youtube.com/watch?v=PLI-1Qm1Lp4

/interface bridge add name=bridge1 vlan-filtering=yes pvid=10
/interface wifiwave2 datapath add bridge=bridge1 name="Local Bridge" vlan-id=10
/interface wifiwave2 set [ find default-name=wifi1 ] configuration.manager=capsman .mode=ap datapath="Local Bridge"
/interface wifiwave2 set [ find default-name=wifi2 ] configuration.manager=capsman .mode=ap datapath="Local Bridge"

HERE IS A VIDEO SHOWING THE ISSUE
https://www.youtube.com/watch?v=PLI-1Qm1Lp4

I'm not sure why the vlan appears twice in the list in your video, but the interface appearing under "tagged" should not be a problem and is correct. If it was untagged then your packets would likely have two tags on them instead of one. See my post above in this thread for more details.

Based on your config you also shouldn't need bridge VLAN filtering turned on at all on the cAP ax for this to work. All that bridge VLAN filtering is doing for you is making it so that you have to do manual work to add VLANs to APs that you normally would not have to do.

#2. BRIDGE/VLAN interface "TAGGED" ports are expected to carry vlan traffic, and should not be applied to an access port weather its physical or wireless( unless your expecting a client to be using tagged vlan traffic ), there are 2x entries in bridge->vlan entries tagged, and untagged, they are both there for a reason!, meaning that a port will be carrying a VLAN, and in my case a wireless port where the traffic egress needs to be sent out as untagged. If you look at bridge ports the PVID is an INGRESS entry ( as per mikrotik doco : "PVID - The Port VLAN ID is used for access ports to tag all ingress traffic with a specific VLAN ID." )

#3. Never trust what a clients are doing, especially an unsecure campus. ALWAYS filter... and it is clearly stated in the Mikrotik documentation for this exact configuration I use: https://help.mikrotik.com/docs/display/ ... agStacking
-> And as stated in highlighted red background on that link.. " Always try to use ingress-filtering wherever it is possible, it adds a significant layer of security.". There is whole paragraphs explaining it on that link..

#4 That bridge port when it dynamically adds the wireless radios, should ideally set the frame type to "frame-types=admit-only-untagged-and-priority-tagged" rather than admit all, but should be select-able depending on expected operations and should be added to wave2 capsman in my opinion as part of port security.

#1. The VLAN should never appear as a secondary entry when its already added to the bridge vlan table when a wireless client connects ( Thats a bug )

#2. BRIDGE/VLAN interface "TAGGED" ports are expected to carry vlan traffic, and should not be applied to an access port weather its physical or wireless( unless your expecting a client to be using tagged vlan traffic )

#3. Never trust what a clients are doing, especially an unsecure campus. ALWAYS filter

#4 That bridge port when it dynamically adds the wireless radios, should ideally set the frame type to "frame-types=admit-only-untagged-and-priority-tagged" rather than admit all

BRIDGE/VLAN interface "TAGGED" ports are expected to carry vlan traffic, and should not be applied to an access port weather its physical or wireless( unless your expecting a client to be using tagged vlan traffic )

The VLAN should never appear as a secondary entry when its already added to the bridge vlan table when a wireless client connects

I confirm that (on 7.12rc1) the Bridge VLAN "Current tagged" column incorrectly lists the wlan interfaces. I have added them both to Tagged for several VLANs, but wlan2 does not appear correctly in "Current tagged" even when a client is connected that uses the VLAN (RADIUS assigned).

*) sfp - fixed link establishment with passive copper cables for RB4011 and CCR2004-16G-2S+ devices (introduced in 7.12rc1);

So, wifi interfaces should in fact be among the tagged ports for the respective bridge VLAN, when VLAN filtering is enabled on the bridge.

So, wifi interfaces should in fact be among the tagged ports for the respective bridge VLAN, when VLAN filtering is enabled on the bridge.

Except if the VLAN of the datapth is the same as the bridge's PVID, right? Because that's how mine behaves.

Not exactly the same as with vlan-id set to 1. wifiwave2 datapath propertiy vlan-id can be unset (as per your example) ... and in that case VLAN tagging is not done by wifiwave2 driver at all (the same as with legacy wlan driver setting of vlan-mode=no-tag). So yes. in this case bridge port implicit pvid setting does the trick (or in case of manual wifiwave2 provisioning, one can set PVID on wireless bridge port explicitly). However, if wifiwave2 datapath vlan-id is set to 1, then wifiwave2 driver will do the tagging in direction towards the rest of network (e.g. bridge, so wireless device will be tagged bridge port and tagged member of VLAN 1).

I don't really get all this tagged/untagged discussion. The 802.11 frame header has no place for a VLAN ID, so, technically, wifi interfaces are never tagged.

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1 hw=no
add bridge=bridge1 interface=ether2 hw=no pvid=20
add bridge=bridge1 interface=ether3 hw=no pvid=30
/interface bridge vlan
add bridge=bridge1 tagged=ether1 untagged=ether2 vlan-ids=20
add bridge=bridge1 tagged=ether1 untagged=ether3 vlan-ids=30
add bridge=bridge1 tagged=ether1,bridge1 vlan-ids=99
/interface vlan
add interface=bridge1 vlan-id=99 name=MGMT
/ip address
add address=192.168.99.1/24 interface=MGMT
/interface bridge
set bridge1 vlan-filtering=yes

/interface bridge vlan
add bridge=bridge1 tagged=ether1,ether2 vlan-ids=20
add bridge=bridge1 tagged=ether1,ether3 vlan-ids=30

Sub-menu: /interface bridge

pvid (integer: 1..4094; Default: 1) Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. It applies e.g. to frames sent from bridge IP and destined to a bridge port. This property only has an effect when vlan-filtering is set to yes.

Sub-menu: /interface bridge vlan

tagged (interfaces; Default: none) Interface list with a VLAN tag adding action in egress.
untagged (interfaces; Default: none) Interface list with a VLAN tag removing action in egress.

On iOS 17 devices, established IKE2 peers will disconnect after 24 minutes of being connected.
The disconnect happened after rekeying sent by the responder and then rejected by the initiator.
ROS = 7.11.2, 7.12rc1
Responder PFS= none

Code: Select all

 14:13:28 ipsec --->IPSEC: -> ike2 request, exchange: CREATE_CHILD_SA:44 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec --->IPSEC: payload seen: ENC (292 bytes)
 14:13:28 ipsec --->IPSEC: processing payload: ENC
 14:13:28 ipsec,debug --->IPSEC: => iv (size 0x10)
 14:13:28 ipsec --->IPSEC: payload seen: NOTIFY (12 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: SA (92 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: NONCE (20 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: KE (72 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: TS_I (24 bytes)
 14:13:28 ipsec --->IPSEC: payload seen: TS_R (24 bytes)
 14:13:28 ipsec --->IPSEC: create child: respond
 14:13:28 ipsec --->IPSEC: processing payloads: NOTIFY
 14:13:28 ipsec --->IPSEC:   notify: REKEY_SA
 14:13:28 ipsec --->IPSEC: rekeying child SA 0xd1dabae
 14:13:28 ipsec --->IPSEC: peer wants tunnel mode
 14:13:28 ipsec --->IPSEC: processing payload: TS_R
 14:13:28 ipsec --->IPSEC: 0.0.0.0/0
 14:13:28 ipsec --->IPSEC: processing payload: TS_I
 14:13:28 ipsec --->IPSEC: 172.18.2.200
 14:13:28 ipsec --->IPSEC: checking: 0.0.0.0/0 <=> 172.18.2.200
 14:13:28 ipsec --->IPSEC: processing payload: SA
 14:13:28 ipsec --->IPSEC: IKE Protocol: ESP
 14:13:28 ipsec --->IPSEC:  proposal #1
 14:13:28 ipsec --->IPSEC:   enc: aes256-cbc
 14:13:28 ipsec --->IPSEC:   auth: sha256
 14:13:28 ipsec --->IPSEC:   dh: ecp256
 14:13:28 ipsec --->IPSEC:  proposal #2
 14:13:28 ipsec --->IPSEC:   enc: aes256-cbc
 14:13:28 ipsec --->IPSEC:   auth: sha256
 14:13:28 ipsec --->IPSEC: matched proposal:
 14:13:28 ipsec --->IPSEC:  proposal #2
 14:13:28 ipsec --->IPSEC:   enc: aes256-cbc
 14:13:28 ipsec --->IPSEC:   auth: sha256
 14:13:28 ipsec --->IPSEC: processing payload: NONCE
 14:13:28 ipsec --->IPSEC: create child: finish
 14:13:28 ipsec --->IPSEC: adding payload: NONCE
 14:13:28 ipsec,debug --->IPSEC: => (size 0x1c)
 14:13:28 ipsec --->IPSEC: initiator selector: 172.18.2.200 
 14:13:28 ipsec --->IPSEC: adding payload: TS_I
 14:13:28 ipsec,debug --->IPSEC: => (size 0x18)
 14:13:28 ipsec --->IPSEC: responder selector: 0.0.0.0/0 
 14:13:28 ipsec --->IPSEC: adding payload: TS_R
 14:13:28 ipsec,debug --->IPSEC: => (size 0x18)
 14:13:28 ipsec --->IPSEC: adding payload: SA
 14:13:28 ipsec,debug --->IPSEC: => (size 0x2c)
 14:13:28 ipsec --->IPSEC: <- ike2 reply, exchange: CREATE_CHILD_SA:44 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec,debug --->IPSEC: ===== sending 256 bytes from responder-ip[4500] to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: 1 times of 260 bytes message will be sent to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: => child keymat (size 0x80)
 14:13:28 ipsec --->IPSEC: IPsec-SA established: initiator-ip[4500]->responder-ip[4500] spi=0xb39e1af
 14:13:28 ipsec,debug --->IPSEC: ===== received 80 bytes from initiator-ip[4500] to responder-ip[4500]
 14:13:28 ipsec --->IPSEC: -> ike2 request, exchange: INFORMATIONAL:45 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec --->IPSEC: payload seen: ENC (52 bytes)
 14:13:28 ipsec --->IPSEC: processing payload: ENC
 14:13:28 ipsec,debug --->IPSEC: => iv (size 0x10)
 14:13:28 ipsec,debug --->IPSEC: decrypted packet
 14:13:28 ipsec --->IPSEC: payload seen: DELETE (12 bytes)
 14:13:28 ipsec --->IPSEC: respond: info
 14:13:28 ipsec --->IPSEC: processing payloads: NOTIFY (none found)
 14:13:28 ipsec --->IPSEC: processing payloads: DELETE
 14:13:28 ipsec --->IPSEC: delete ESP SA
 14:13:28 ipsec --->IPSEC: delete spi: 0xd1dabae
 14:13:28 ipsec --->IPSEC: IPsec-SA established: responder-ip[4500]->initiator-ip[4500] spi=0xde365b1
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: initiator-ip[4500]->responder-ip[4500] spi=0xe8c243e
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: responder-ip[4500]->initiator-ip[4500] spi=0xd1dabae
 14:13:28 ipsec,debug --->IPSEC: sending empty reply
 14:13:28 ipsec --->IPSEC: <- ike2 reply, exchange: INFORMATIONAL:45 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec,debug --->IPSEC: ===== sending 160 bytes from responder-ip[4500] to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: 1 times of 164 bytes message will be sent to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: ===== received 80 bytes from initiator-ip[4500] to responder-ip[4500]
 14:13:28 ipsec --->IPSEC: -> ike2 request, exchange: INFORMATIONAL:46 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec --->IPSEC: payload seen: ENC (52 bytes)
 14:13:28 ipsec --->IPSEC: processing payload: ENC
 14:13:28 ipsec,debug --->IPSEC: => iv (size 0x10)
 14:13:28 ipsec,debug --->IPSEC: decrypted packet
 14:13:28 ipsec --->IPSEC: payload seen: DELETE (8 bytes)
 14:13:28 ipsec --->IPSEC: respond: info
 14:13:28 ipsec --->IPSEC: processing payloads: NOTIFY (none found)
 14:13:28 ipsec --->IPSEC: processing payloads: DELETE
 14:13:28 ipsec --->IPSEC: delete IKE SA
 14:13:28 ipsec --->IPSEC: <- ike2 reply, exchange: INFORMATIONAL:46 initiator-ip[4500] c6d3a55dca1d4567:016061474fafcdab
 14:13:28 ipsec,debug --->IPSEC: ===== sending 128 bytes from responder-ip[4500] to initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: 1 times of 132 bytes message will be sent to initiator-ip[4500]
 14:13:28 ipsec,info killing ike2 SA: IKE2 responder-ip[4500]-initiator-ip[4500] spi:016061474fafcdab:c6d3a55dca1d4567
 14:13:28 ipsec,info --->IPSEC: killing ike2 SA: IKE2 responder-ip[4500]-initiator-ip[4500] spi:016061474fafcdab:c6d3a55dca1d4567
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: initiator-ip[4500]->responder-ip[4500] spi=0xb39e1af
 14:13:28 ipsec --->IPSEC: IPsec-SA killing: responder-ip[4500]->initiator-ip[4500] spi=0xde365b1
 14:13:28 ipsec --->IPSEC: removing generated policy
 14:13:28 ipsec --->IPSEC: KA remove: responder-ip[4500]->initiator-ip[4500]
 14:13:28 ipsec,debug --->IPSEC: KA tree dump: responder-ip[4500]->initiator-ip[4500] (in_use=1)
 14:13:28 ipsec,debug --->IPSEC: KA removing this one...
 14:13:28 ipsec,info releasing address 172.18.2.200
 14:13:28 ipsec,info --->IPSEC: releasing address 172.18.2.200

If we were to wind back a bit regarding tagging/vlan and go back to documented basics

*) sfp - fixed link establishment with passive copper cables for RB4011 and CCR2004-16G-2S+ devices (introduced in 7.12rc1);

https://mikrotik.com/product/rb4011igs_rm says "Note: Passive DAC (MikroTik S+DA0001/S+DA0003) are not supported." - are they supported now?
Or is this a mistake in the changelog and only applies to CCR2004-16G-2S+?

Yes, that is a common issue with IPsec. People configure "more secure" IPsec settings (PFS, 256 bits, DH with long keys) and then it only works between routers but not with commonly used client devices...
The worst is that it requires ongoing research to know what settings are supported in each version of the client operating systems.

Could you please generate a supout file on your router after IPsec has experienced unexpected disconnect and send it to support@mikrotik.com?

Without any evidence we can not be sure about that, but seems that the problem might not be caused by the RouterOS:
https://forums.macrumors.com/threads/so ... s.2406029/

If we were to wind back a bit regarding tagging/vlan and go back to documented basics

Upgrading from v6.9x to 7.12rc2 all bgp, mpls, ospf settimg all missing.

Thx

Upgrading from v6.9x to 7.12rc2 all bgp, mpls, ospf settimg all missing.

Thx

What did you expect...just upgrade and continue? You just moved to a new major version!

One of my DAC's […]

Do you have a SUP ticket to reference for this? Thank you!

While there have been reports left and right about problems in 7.11 chain, I've successfully used netinstall on multiple devices with 7.10
So broken in 7.x is not correct.

This time I manually rebooted the router before trying to install the update, and the reboot was hanging. Just like the update is hanging when I try it after some uptime.
Could it be caused by rose-storage? I have an NFS mount (the router mounts a share from an NFS server). I could imagine that this is not unmounted before the interfaces go down, and then it takes a long time to unmount the NFS share in the reboot procedure (I don't have much patience, after a minute or two I just powercycle the router).
Are there others who use NFS mount that experience problems rebooting?

/disk
add nfs-address=192.168.1.3 nfs-share=/local/mikrotik slot=nfs type=nfs

On iOS 17 devices, established IKE2 peers will disconnect after 24 minutes of being connected.

It seems that the bridge and/or the ethernet port is taken down before the NFS share is unmounted?

So what seems to be the problem in ROS is that on shutdown/reboot sequence, NFS server doesn't get stopped. Hence exported disk partition still shows usage and unmounting it hangs.

When are you releasing 7.12? I need those IKEv2 rekey fixes in the stable version :)

When are you releasing 7.12? I need those IKEv2 rekey fixes in the stable version

When are you releasing 7.12? I need those IKEv2 rekey fixes in the stable version :)

when its done :)

I don't really get all this tagged/untagged discussion. The 802.11 frame header has no place for a VLAN ID, so, technically, wifi interfaces are never tagged.

When are you releasing 7.12? I need those IKEv2 rekey fixes in the stable version :)

I don't really get all this tagged/untagged discussion. The 802.11 frame header has no place for a VLAN ID, so, technically, wifi interfaces are never tagged.

Well 802.11 standard frame has no space for a VLAN tag, and only has space for 3 MAC addresses.
But MT with WLAN driver "AP bridge"-"station bridge" connection, not only passes the 4th MAC address (sender-transmitter-receiver-destination) , but also the VLAN tags work as expected on a bridged ethernet connection.
Access, trunk, hybrid ... it all works over that wifi link. (And I see the same on CUBE's 60GHz wireless-wire links.)
Maybe it comes also in WLAN-WDS interfaces. ??? viewtopic.php?t=14300 ?????????????????

I don't really get all this tagged/untagged discussion. The 802.11 frame header has no place for a VLAN ID, so, technically, wifi interfaces are never tagged.

Well 802.11 standard frame has no space for a VLAN tag, and only has space for 3 MAC addresses.
But MT with WLAN driver "AP bridge"-"station bridge" connection, not only passes the 4th MAC address (sender-transmitter-receiver-destination) , but also the VLAN tags work as expected on a bridged ethernet connection.

However, different wireless drivers do interact with passing frames beyond basic MAC addressing and some drivers might burp on frames they don't recognize.

However, different wireless drivers do interact with passing frames beyond basic MAC addressing and some drivers might burp on frames they don't recognize.

I think the problem is that the drivers have to do some kind of workaround to replace ARP. The WiFi has the same MAC for all clients, but they still need to send the appropriate packets to the correct MAC. To do that, the driver assumes the packet is IP and peeks into the header to see the destination IP. But that fails when the next header is VLAN.

However, different wireless drivers do interact with passing frames beyond basic MAC addressing and some drivers might burp on frames they don't recognize.

I think the problem is that the drivers have to do some kind of workaround to replace ARP. The WiFi has the same MAC for all clients, but they still need to send the appropriate packets to the correct MAC. To do that, the driver assumes the packet is IP and peeks into the header to see the destination IP. But that fails when the next header is VLAN.

hAP AX LTE6 aka L41G-2axD&FG621-EA has an annoying glitch:

- Although I have entered 0000 as PIN for LTE card, after reboot ROS 7.8, 7.11.2 and 7.12rc2 all say "SIM locked" and no LTE traffic. Log says: LTE:: lte1 mbim: state 7=>9
- problem gets fixed after doing disable+enable to the lte1 interface: now interface knows the PIN and goes up correctly
- LTE firmware 16121.1034.00.01.01.04

hAP AX LTE6 aka L41G-2axD&FG621-EA has an annoying glitch:

- Although I have entered 0000 as PIN for LTE card, after reboot ROS 7.8, 7.11.2 and 7.12rc2 all say "SIM locked" and no LTE traffic. Log says: LTE:: lte1 mbim: state 7=>9
- problem gets fixed after doing disable+enable to the lte1 interface: now interface knows the PIN and goes up correctly
- LTE firmware 16121.1034.00.01.01.04

This is an old problem.
I solved it on my ax lte disabling pin on the used SIM ( you need to put it in a smartphone to do that).

You could also use a script on startup to disable and enable lte.

/interface/lte at-chat lte1 input="AT+CLCK=\"SC\",0,<pin>"

/interface/lte at-chat lte1 input="AT+CLCK=\"SC\",1,<pin>"

/interface/lte at-chat lte1 input="AT+CPWD=\"SC\",<oldPIN>,<newPIN>"

/interface/lte at-chat lte1 input="AT+CLCK=\"SC\",2"

*) poe-out - removed "auto" mode support for L009 devices;

• `bgpLocalAs` (https://oidref.com/1.3.6.1.2.1.15.2) and,
• `bgpIdentifier` (https://oidref.com/1.3.6.1.2.1.15.4)

• `bgpPeerFsmEstablishedTime` (https://oidref.com/1.3.6.1.2.1.15.3.1.16); this one should indicate how long (in seconds) this peer has been in the Established state or how long since this peer was last in the Established state.

Code: Select all

system - fixed process multithreading (introduced in v7.9);

care to elaborate please?

Code: Select all

system - fixed process multithreading (introduced in v7.9);

care to elaborate please?

Noted after installation (do no know how long it exists as I just changed IPv6 settings) that when you have IPv6 enabled but IPv6 routing disabled, the IPv6 forward chain gets hit with multicast packets from the local network, as if it wants to forward them.

Code: Select all

/ipv6 settings
set forward=no
/ipv6 firewall filter
add action=drop chain=forward log=yes

I would think when forwarding is disabled, no attempts to forward should be made.

Since version 7.9 few processes were not working properly and could have caused an extra load on single CPU core, compared to older versions. That was caused due to the fact that parallel processes were not started as separate tasks. For example, this did affect SSL processes, certificate management processes, PPP tunnels, etc.

Kind of a classical "single core stuck on 100%" or "process X is being handled only by a single CPU core" problems.

For example, simple traffic processing was not affected.

Noted after installation (do no know how long it exists as I just changed IPv6 settings) that when you have IPv6 enabled but IPv6 routing disabled, the IPv6 forward chain gets hit with multicast packets from the local network, as if it wants to forward them.

I've put that drop rule with log into 7.12rc2 and I'm not seeing any logged packets.

For example, this did affect SSL processes, certificate management processes, PPP tunnels, etc.

Since version 7.9 few processes were not working properly and could have caused an extra load on single CPU core, compared to older versions. That was caused due to the fact that parallel processes were not started as separate tasks. For example, this did affect SSL processes, certificate management processes, PPP tunnels, etc.

Kind of a classical "single core stuck on 100%" or "process X is being handled only by a single CPU core" problems.

For example, simple traffic processing was not affected.

Minor webfig error with RC2 (not sure if it happened on RC1, screenshot is from RC2), there's an erroneous TX/RX rates (that keeps updating) on the header, no matter which "page" I'm in. It's not supposed to be there.
.
EDIT: disabled my skin and the information is still there, so not skin related.
.
RC2.png

Minor webfig error with RC2 (not sure if it happened on RC1, screenshot is from RC2), there's an erroneous TX/RX rates (that keeps updating) on the header, no matter which "page" I'm in. It's not supposed to be there.
.
EDIT: disabled my skin and the information is still there, so not skin related.
.
RC2.png

These values are there for a purpose. Is there a problem with them?

These values are there for a purpose. Is there a problem with them?

I presume these figures are the TX/RX rate of the connection with webfig. People probably assume these are the global TX/RX rate of the router (same as was on the LCD back in the old days)?

These values are there for a purpose. Is there a problem with them?

I presume these figures are the TX/RX rate of the connection with webfig.

Hold on, you're right, it is just webfig traffic. I thought it was total traffic, which be okay. But not sure what webfig traffic usage shows...

It shows how much traffic it takes to display and update the page you are viewing in webfig.

While we're at it. It would be nice to be able to disable Winbox Graphics Licence and Help for the RouterOS login screen.

And also the note

You have connected to a router. Administrative access only. If this device is not in your possession, please contact your local network administrator.

Plus maybe be able to change it if we like.

TIA

Is BTH going to be in the eventual stable?

Not quite true... Also running the combination with Wireguard and OSPF on 7.12rc4 already.