Post 7.13 incompatible station bridge versions

RouterOS General
1

Having seen the reports that 7.16beta7 has fixed/improved many items, and the reported problems seem to be for advanced routing I don’t use, I felt like upgrading. And having upgraded my main router to 7.16beta7 I could use Dude again for such upgrades. I just upgraded all my remote devices, that were v7 but well under 7.13, to 7.16beta7. And most of them did just fine. The two exceptions were wireless stations, not AP’s, and they lost wireless connectivity until I visited the sites and fixed them.

I did learn, or re-learn, or just have a not-so-gentle reminder, not to do upgrades unless I really really need to and not to do so unless I have physical access to the units. But that’s not the point here.

My first affected site was a hAP AC2. For that one, moving from I believe 7.8, I installed the wireless package and things came up pretty quickly. The site AP was non-Mikrotik so there wasn’t anything else to play with. The hAP is showing 14.6MB of 16MB used - which if I recall is an issue which can be corrected by doing a Netinstall. I didn’t want to go through that, the site was functional, so I’m leaving it.

The second site is what prompted this post. There I have an Audience AP and a mAP station. The Audience had the wifi-qcom-ac package installed - but I didn’t realize that the interfaces created by this package are different than those created by the (now deactivated) wireless package. So my wireless interfaces were not in the bridge. Adding the ports to the bridge solved the first problem - now there was wifi available in the area.

Then I went to the mAP. Like the hAP I had to install the wireless package. Then the fun started. The mAP connected via wifi - but I could not get any IP traffic to flow. Some time later - I found the instructions that the “station-bridge” of wireless is incompatible with a “wifi” package AP. I kept fighting it - until I gave in, set the wlan interface to “station” removed the wlan interface from the bridge, and then the wlan dhcp-client worked. Then I had to figure out how to connect the ethernet ports to the wlan where it was previously handled through the simple bridge.

So I setup a DHCP server on the mAP ethernet bridge (for the IoT device plugged into it) and adjusted the srcnat/dstnat rules accordingly…and traffic flowed. Done. Packed up and ran away.

So the question now…besides all the good practices I should have followed and am now preparing against future needs - should I have configured things differently? Could I have used the “wireless” package on the Audience and retained the station-bridge function on the mAP? Was there another way to accomplish the goal of providing a PtP wifi connection from the mAP to the Audience?

2

Yes, you could have used the wireless package, and the map could then connect in station bridge.
Wifi package does have some niceish features though.

Other options:

Use Station-Pseudo bridge mode.
Ok when it works, need to turn off RSTP. If you go this way and it’s not behaving it is worth searching these forums.

Run the map in Station mode and have an EOIP tunnel connecting the Audience bridge to the map’s bridge.

3

Well, I know you did not come here to hear this - but I have to say it because all you described sounds like a typical YOLO quest. You upgraded all your devices to some 7.16beta7 straight away from ROS versions “well below 7.13”. OK, you can do it. But then please read the changelog beforehand and the documentation:

That would have saved you a lot of trouble and blame-game and maybe you did not even felt the urge to post this topic at all.

I know, Mikrotik does not make it easy for people to find all the information. Their changelogs are “suboptimal” (very kindly said). There is a LOT of hidden infos sprinkled around multiple sources. Most of it is somewhere in their ROS “docs” (https://help.mikrotik.com/docs/display/ROS), some minimal “keywords” are inside their changelogs. They could have all that information from the above two links included in their changelog - but they did not. Because their point of view is: “it is just a extraction of legacy wireless drivers to an extra package. that is done automatically. Nothing else changes for the user”. Valid argumentation as well.

I think you would not get into that situation, when Mikrotik would write more detailled changelogs. I mean, look at the 7.13 changelog:

Notice - Starting from RouterOS version 7.13, significant changes have been made to the RouterOS wireless packages. This is done due to a new product development which will require more disk space for hardware drivers so we had to split it in order to maintain old products alongside the new ones. More wireless packages are yet to come.

  1. When upgrading by using “check-for-updates”, all versions earlier than 7.12 will display 7.12 as the latest available version. Upgrade from v7.12 to v7.13 or later versions must be done through 7.12 in order to convert wireless packages automatically. Fresh installation with Netinstall or manual package installation works in the same manner as always.

  2. Drivers for older wireless and 60GHz interfaces, as well as the wireless management system CAPsMAN, are now part of a separate “wireless” package instead of being a part of the bundle package. This package can be uninstalled if not needed.

  3. The existing “wifiwave2” package has been divided into distinct packages: “wifi-qcom” and “wifi-qcom-ac”, and the necessary utilities for WiFi management are now included in the RouterOS bundle. RouterOS and “wifi-qcom-ac” packages alongside each other now fit into 16MB flash memory.


    What’s new in 7.13 (2023-Dec-14 09:24):

!) package - convert “wireless” and “wifi” packages automatically, if upgrading from v7.12;
!) wifi - split existing “wifiwave2” package into separate packages “wifi-qcom”, “wifi-qcom-ac”, and include required utilities for WiFi management into bundle;
!) wireless - separate “wireless” package from bundle and build as a standalone package;

That is pretty all and nothing about the migration to wifi-qcom(-ac).

How I would read it, when not used to Mikrotik jargon: “Yeah, they split up wifi packages. Hm, automatically migrated. cool. looks legit. can’t go wrong. hit upgrade.”

Mostly true, if you do just that. Hit upgrade and keep it. Once you start fiddling with the new wifi packages on AC devices: the game starts.

How one must read it: “Holy moly! So much words and first 3 lines are prefixed with “!)”. Phew. When Latvians talk/write so much, this must be some serious thing. Better read all the docs I can find, visit the forum, search for issues, read the release threads, go to lab and try first out what happens after migrating to wifi-qcom-ac package. Compatibility? And take time, as I can expect this consumes well some pretty amount of time to have all that information ready that Mikrotik did not include in their changelog”

And finally, regarding your Audience 2 mAP link: you can try “station-pseudobrige” as a 1:1 replacement for “station-bridge”. It may give you some trouble which may be resolved by setting “protocol-mode=none” on your mAP’s bridge.