Sorry, I mean seriously, I thought you remembered that. It’s a feature that backfired…
Well … I can’t say that I remember the correlation between the two events. Although I agree that they may have happened around the same time.
I’ll refresh it for you briefly:
Sometimes the “BIOS” gets confused and formats the NAND/Flash thinking that the protected-routerboot device reset procedure has been activated,
causing the classic continuous boot-loop which can only be resolved by netinstalling the device.
The latest version, that I know of, that doesn’t do this randomly is 6.44.6.
Frequent disconnects from the different WiFi SSIDs that I have available using VLAN segration. This never used to happen on this magnitude before upgrading to ROS 7.15.2. I am hoping that ROS 7.16 which is in beta and testing fixing whatever issues 7.15.2. Other than I am planning on reloading a backup of the configurations that I have and wiping out the current one that I have installed. If you have any feedback on how to resolve that would be welcomed also. Thank you.
No Wifi problems for me on 2 setups using 7.15.2…RB2011+cAp ax and RB4011+cAP ax, with VLANs managed by CAPsMAN. So the issues you and others have must be HW or config specific.
I am deeply scared. How can this be possible…
OK, so I did some more testing, and have some positive results:
/interface wifi security add authentication-types=wpa2-psk connect-priority=0/1 disabled=no encryption=ccmp ft=yes ft-preserve-vlanid=no name=sec1
I have added “connect-priority=0/1” and “encryption=ccmp”, removed “ft-over-ds=yes”.
After this, there is only one client left with “SA query timeouts” and even that is showing rarely.
Next, I’ll try to change everything back, one by one, and see when timeouts start again… Or I might upgrade again to 7.15 or 7.16 first, we’ll see.
To me “reset config leaves some stuff invisible” sounds like a ghost story, and I doubt you have any tangible proof of that, for example router is doing something it is not configured to do, except your gut filing I mean…
Anyways I installed V6 after V7 and resetting configuration so if anything those ghost leftovers, if any, made my router run much faster…
Just install on CHR / x86, do experiments, do reset configuration and…
disconnected, SA Query timeout, signal strength -61
Anyone seeing excessive SQ Query timeouts should try to set “security.management-protection=disabled”.
Mikrotik should make “SA Query RetryTimeout” configurable in ROS WIFI menu. So people can adjust themselves within a given range. Cambium for example allows a range of 100ms-500ms.
After my move from 7.15 to 7.15.2
I keep seeing
LACPtoSwitches: bridge RX looped packet - MAC 18:fd:74:78:3b:9b -> ff:ff:ff:ff:ff:ff VID 80 ETHERTYPE 0x0800 IP UDP 0.0.0.0:68 -> 255.255.255.255:67
LACPtoSwitches is a bond to a set of MLAG switches.
18:fd:74:78:3b:9b is my eth6 on my Router (5009) which connects an CAPAX.
All devices are the same version.
I do see something funky on the capAX. Wireless is controlled by capsman on the 5009.
On the capax, bridge, ports, I see each of the dynamically created wireless interfaces, and it lists a PVID.
On the bridge > vlan tab, It lists each of those dynamically created wireless interfaces, with their vlan as tagged on the interface. As far as I remember, an interface cannot be tagged and untagged for the same vlan.
While I think what is meant is that this is untagged for each of these interfaces, both winbox and cli print shows the same information. Who knows if this is by design or by accident.
I think Mikrotik read an all Buffalo networks manual, and said… you know what would be cool?
The rest is history.
Yet, we still don’t have lock on first mac for any of the CRS3x switches.
That looks like a DHCP-request being looped. Verify at the other end of these cables that the LACP is correctly setup. If there is a MLAG over there make sure that the MLAG-PEER is working and that both interfaces towards your box uses the same mlag-id. Then verify that pvid and tagged (if used) vlan configuration is setup correctly.
When it comes to vlans you can technically have the same vlan untagged and tagged at the same time since you got two directions.
That is PVID defines which VLAN untagged frame arrives should be considered to belong to. But also for which internal VLAN should the tag be removed when sent out on this interface. But at the same time you can also receive tagged frames if the opposite side is incorrectly configured and they have have the same vlanid as the PVID on your end. And normally you want to have an “allowed-vlan” list on your end to deal with that.
For example you have pvid=100 along with allowed-vlan=100 (and hybrid interface) that means that:
- Sending frames from your vlan100 will have the 801.2Q tag stripped before egressing the interface (aka sent as untagged frames).
- Untagged frames arriving on this interface will be considered to be part of vlan100 so a 802.1Q tag of vlan-id:100 is set to the frame when handled internally.
- Frames with 802.1Q set to vlan-id:100 who arrives at this interface will be allowed aswell, any other tagged frames will be dropped.
Note when it comes to the interface configuration you have normally:
- Access: Only accepts and send out untagged frames.
- Trunk: Only accepts and send out tagged frames.
- Hybrid: Accepts both untagged and tagged frames in both directions.
Note that for trunk interface there can still be control packets who are not tagged being sent out (or received) like LACP, LLDP/CDP and sometimes STP.
And for even more complex setups hybrid interface can be used to deal with multiple untagged vlans at once along with protocolbased vlans.
For example you can egress frames for both vlan 400 and 601 but for ingress frames ethertype IPv4 + ARP is considered to be part of vlan400 and ethertype IPv6 is considered to be part of vlan601.
If we’re talking about bridge with vlan-filtering=yes, then pvid setting only affects untagged frames on ingress. Untagging on egress is (strictly speaking) controlled by setting untagged property under /interface/bridge/vlan … indeed setting pvid will automatically add a (dynamic) entry to that table, but if one explicitly sets same port as tagged there, then it’s up to anyone’s guess as to what happens (some MT dev might know the answer).
Can any one Explain what dose this option do?
Found this in V7.15.2
If is set it to Long what will happen
and what will happen if i set it to short.
Manual is still not updated.
Short mode is 16 bits and long mode is 32 bits for path cost. The same mode needs to be set on all switches in the network to function.
I found it for you.
Note that this is a complete mess if you got a multivendor environment and want to use STP:
The IEEE 802.1D specification assigns 16-bit (short) default port cost values to each port that is based on bandwidth. You can also manually assign port costs between 1-65535. The 16-bit values are only used for ports that have not been specifically configured for port cost.
802.1t assigns 32-bit (long) default port cost values to each port using a formula that is based on the port bandwidth. You can also manually assign port costs between 1-200,000,000. The formula for obtaining default 32-bit port costs is to divide the bandwidth of the port by 200,000,000.
Along with that for example Cisco IOS up to version 16.03.069 the default were short but since 16.0.6.x the default is long.
So make sure that the portcost is manually set to either short or long (were long is the prefered if all your devices supports this).
Thank you so much for quick response
I use one hEX device with external USB SSD (formatted as ext4) as Dude server. Suddenly I noticed that Files menu was unable to display any files on that disk, while Dude and all else using the disk were working absolutely fine.
Reboot did not help. After I “ejected” the disk, disconnected and reconnected it all files were displayed again and all was OK…