You can’t use station bridge mode between old wireless and new wifi driver, it requires the same driver on both sides. This is documented in the manual.
OK, but why device with the wifi card /AR9888/ with old drivers on RBM33G, works with a device with new drivers /cAP AC/ in station pseudobridge mode transparently?
Because station-pseudobridge uses standard 802.11 over the air, the “pseudobridge” magic happens entirely inside station device while “bridge” part of station-bridge uses non-standard extensions of 802.11 over the air … and those extensions are in principle incompatible between different vendors. MT started to use chipset-producer drivers and thus became incompatible with themselves (previously drivers were made by MT). Which makes me believe there willl be another incompatibility if/when MT starts to use wifi chipsets not made by Qualcomm.
The “transparently” part of your question is yet another thing. station-pseudobridge is not truly transparent in sense that L2 properties (MAC addresses) are masked off … and that causes problems with any services which rely on transparency of L2 (ARP tables, DHCP protocol, etc.).
Thank you @mkx . My question is why BaseBox2 can’t connect or can’t set station modes with bridge, but other radio can - in this case rbm33g with AR9888 , if we claim that something is not possible with old drivers? Basebox2 can’t create station pseudobridge, RBM33G can?
@JohnTRIVOLTA, I think you should focus on getting straight “station” to pass traffic. That’s the most straight forward station mode and should work in any case, regardless the vendor and/or driver generation of either AP or station. After you get station working, pseudobridge should be a relatively easy task.
But make sure the other end is not set to “bridge”, it has to run either as “AP” or “AP-bridge”.
You were all correct.
I set up a VPN to my edge router, so I could test the process using a “local” IP instead of Zerotier.
After removing Zerotier, I was able to load wifi-qcom-ac and the interfaces were visible and could be configured.
After all of that I decided to roll back though, as Zerotier is more important (ability to remotely manage) for me at the moment.
I will check in future if there is more unbundling taking place, and whether I will be able to get wifi-qcom-ac and Zerotier running together.
A few of the core components are not really vital to me, as the HAP AC2s I have are just APs, the edge device is an RB5009 where I need full functionality.
It is really a pity that storage is so limited on the HAP AC2, as it is otherwise an excellent device.
I would consider upgrading all my HAP AC2s to HAP AX2s, but the AX2s do not have an USB port, which I use on the AC2s to drive small ESP32 cameras (small enough power requirement to work quite well).
That leaves me with the AX3 as an option, but the size and price difference does not justify it.
If only we had an USB port on the AX2, or a similarly specced device at a similar price point to the AX2 with an USB port.
Mikrotik - consider bringing out a HAP AX2.5-U (AX2 with an USB port and same small size)
Let’s see what the future holds.
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
206 Partial Content
The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.
Mikrotik has implemented changes to the “fetch” command.
*) fetch - added “http-auth-scheme” parameter, allows to select HTTP basic or digest authentication;
*) fetch - added “http-content-encoding” setting;
*) fetch - added raw logging;
*) fetch - allow to receive HTTP response headers;
*) fetch - require “ftp” user policy;
Thank you @mkx! Station standalone mode works on both boards /Basebox2 or RBM33G/, but i don’t want L3 with EoiP/VPLS for the L2 transparent connectivity! My question is why basebox2 can’t work in this mode /station pseduebridge, others modes not works with bridge/ like the RBM33G , both with same ros version and old drivers, if the problem is the old driver only?
If basebox2 works in station mode but not in station-pseudobridge, then it’s the pseudobridge function on basebox2 which is broken. Pseudobridge doesn’t “offload” anything on the other end if the radio link.
That’s interesting. When I went to 7.13 it broke my slave configurations. Running on a HAP AC. Took me a bit to troubleshoot then went back to 7.12.1 and had to reload (same) config for it to come back. Debating on trying again today.
Basebox2 does not work in any mode and rbm33g only works with station pseudobridge great like station bridge , but why?
@whatever wrote:
“You can’t use station bridge mode between old wireless and new wifi driver, it requires the same driver on both sides. This is documented in the manual.”
I upgrading my SOHO network from 7.12 (no ax router) and my main hAP ac2 went apparently ok… until next morning when I did another /export and it entered a boot loop
Apparently the “old” capsman configuration was crashing the machine soon after reboot, with a message about a critical program crashing, and I had to reset the configuration to get it back to live.
Now I’m re-doing the configuration carefully. Still have not re-joined the two capman “slaves”, and I’m afraid it will enter the loop again.
I’m using the wireless package. Is there any known problem with “old” capsman config in 7.13?
I’ve got the same problem with a Huawei E3372h-153. I’ve also got a E3372h-320 that seems to work fine.
But the E3372h-153 just disappears. It goes up for a split second and then goes down. Tried in a RB5009 and a AX3. I’ve also tried with a RB2011 and it works for a few seconds after restart, but then RX/TX stays at 0 mbps. I ended up downgrading to 7.12 and works fine again. There’s definitely something broken in 7.13.
Also, after upgrading +30 devices, I’ve got a problem with a CRS328: interfaces didn’t go up after upgrade. I had to connect using the console cable and observed there were 0 bytes left. After deleting some files and the wireless package, it booted correctly.
Well, make up your mind, you wrote in your previous post that …
Station standalone mode works on both boards /Basebox2 or RBM33G/
Make a difference between wifi station mode alone and wifi station mode as a bridgeport in the bridge!
Why would you add a station mode interface to a bridge? This makes no sense at all and cannot produce any usable result.
Тo try to somehow get l2 connectivity working.
Leave this modе aside, the question isn’t about it.
Why station pseudobridge work with old drivers on RBM33G, but not with basebox2 ? This is my question!
IMO wifi interface in straight station mode is useless as bridge port by definition. Because only that particular device (as an L3 entity) can communicate via wireless in station mode.
As I already wrote: it is probably a bug … either in ROS on basebox2 or in config applied to basebox2. If you suspect a bug in ROS (I guess you do), then make supout.rif of non-working basebox2 (and preferably of the working vasebox2 running 7.12.1 for a refrence) and send them to Mikrotik to investigate.
Focus on the question that interests me please! I tested again with a different board/NetMetal 5/ and with the old driver work in station pseudobridge mode too. If the driver incompatibility old/new was a problem, why some boards can work, other not?