2.5.4 Firmare for A5-14, A5c, C5# and B24 has been released

This is just my summary of the notes and what I think is important. You can read the notes in their entirety here:

Note 1: I say C5# to refer to the entire C5/C5c/C5x Line.

Note 2: 2.5.4 is not for the A5x. Someday there will be one firmware version to rule them all, one firmware version to bind them and one firmware version to do diagnostics on, but not today.

Many of the features/fixes/improvements and such are platform wide, if there are unique differences then I will note them where I find them interesting.

Resolved Issues:

  • Some security fixes, Remote Code Execution, Cross Site Scripting as well as attacks that could be performed on A5/A5c radios if you were connected to the 2.4 GHz management. probably a good idea to update for these. Check the notes for more details.(Also, put a password on your 2.4 GHz management interfaces)
  • FIX FOR C5 CLIENT REBOOTING WITH REASON “Ethernet Inactivity”. @Derek2, @Ardi, @Stuart7 I hope will all be happy about this solution.
  • Some bugs that would cause random reboots in A5/A5c (including the error code 5000 issue) devices as well as a fix for people being unable to access the A5/A5c management page. @Cesar_Javier might be happy to hear his issue will be permanently fixed.
  • Some ZTP and DHCP option-67 fixes, if you are using these you will probably want to update.

New Stuff:

  • Ability to connect to a Mimisa Self-hosted NMS. Are you tired of Mimosa spending buckets of money on Amazon hosting every month to host your data? Do you want to run a network that doesn’t touch the internet at all, but still want the Mimosa Cloud monitoring features? Then this is the beta for you. Note, you will want quite a bit of storage space for your server, minimally 100 GB and a touch of performance to keep things moving. Hit up @DustinS at his email dstock@airspan.com with your cloud account email and he will hook you up.
  • Aggregate Tx and Rx PHY rate SNMP OIDs, a request I made to Mimosa personally a while back. @David6 might also be happy that some of his feature requests are being heard and taken care of.
  • Channel Return Time, if you think your DFS channel should be clean and any hits you are going to get will be spurious, this feature is for you. I am not certain where I stand on this feature, your radio cannot return to the DFS channel for a minimum of 30 minutes and there is nothing preventing your radio from getting another hit again, so it just seems like a whole new set of problems, but then again… The more I think about it the more I like the idea… Maybe, I dunno, put your comments below about what you think of the feature.

Known Issues:

  • A5/A5c Devices may lose connectivity with Mimosa Cloud or Self-hosted NMS server at times due to network issues. If the device does not connect back, then disable and re-enable Cloud access in WebUI.

If you have your own thoughts about the Release Notes or new features, feel free to comment below. If you are having issues with the new firmware please post a new topic and don’t comment about it in this topic. This is my topic and my notes, I am not affiliated with Mimosa and my thoughts/feelings/actions are my own.

1 Like



Cesar Javier Robles


Tel: 0266-4453540

Cel.: 2664563201

WEB: www.windnet.com.ar

email: jrobles@windnet.com.ar

Dirección: Zona Comercial La Punta, Mza. 130 Local 10 – Ciudad de La Punta // Av. A. Illia 81 – San Luis



  • |

DeclaraciĂłn de Privacidad

Este mensaje y sus anexos son confidenciales y de uso exclusivo por parte del titular de la dirección de correo electrónico a la que está dirigido.

Este mail puede contener informaciĂłn amparada por el secreto comercial y cuyo uso inadecuado puede derivar en responsabilidad civil para el usuario

o configurar los delitos previstos en los artĂ­culos 153 a 157 del CĂłdigo Penal, por lo que su contenido no debe ser copiado, enviado,

revelado o utilizado en cualquier forma no autorizada expresamente por el emisor. En caso de que Ud. no sea el destinatario especificado en este mensaje

o persona debidamente autorizada por el mismo, por favor comunĂ­quelo inmediatamente al remitente y destruya el mensaje sin copiar ni divulgar su contenido.

When can we expect a 2.8.X style firmware on the A5’s? We could REALLY use the vlan tag feature!

1 Like


Do you mean like the ability to have multiple tagged VLANs passed to a single CPE?

I don’t work for Mimosa or have any insider knowledge, so I don’t know when the A5 line will get the 2.8.x firmware. I would figure eventually because the need to have 2 different firmwares for the C5# line is a PITA and probably is a support nightmare for Mimosa.

1 Like

I am waiting for the feature to tag vlans on the AP side for CPE clients. I have a setup where we have a trunk port to the AP, then the AP would tag vlans per CPE client.

edit: meant to say where the CPE would tag vlans! Preferably the AP could provision the CPE (C5# to do so)

1 Like

Trunk to the A5, then each CPE gets one VLAN that it untags to the customer?

That’s already available I use it.

Hey William,

Thanks for the response! I am looking to tag customer traffic connected to the CPE, not just the CPE itself. Should have been more clear on that point. As of now I have to add a router to tag traffic behind C5x’s.

So built my network out to best support:

Switch(management vlan) <-trunk-> A5(management vlan) <-trunk-> C5x (management vlan) <-[Tagging occurring here]-> Customer Equipment (customer vlan).

The C5x has the ability when on 2.8.X but we cannot upgrade them since the A5 does not have a 2.8.X version yet.

You want to be able to send tagged traffic to the customer? Are you wanting to send multiple VLANs to a single customer?

I want the customers traffic to be tagged in the C5x ethernet’s ingress traffic and untagged in the C5x ethernet’s egress traffic

What do you mean by “tagged in the C5x ethernet’s ingress”? Going from the C5x’s CPU to the Ethernet Interface or coming from the customer? Normally I would say “ingress” means coming from the copper (the Cat5e/Cat6 cable) side of the Ethernet port and “egress” would be going out the copper side of the port.

You are correct in thinking the copper port. Customer traffic would be tagged going out to the AP from C5x ethernet port (ingress). Tags would be need to be removed coming back in from the AP requiring removal by the C5x as it leaves the ethernet port (egress) .

We have a similar setup with MT APs where MT will do just that.

edit: Sorry I confused myself at first! Had to adjust!

So like this:

From Customer to our router

customer → C5x eth1 → add vlan X to ingress/incoming traffic → out wlan to AP connected to trunk port on switch → so on to router

From our router to Customer

router sends tagged frame vlan X to switch → AP sends to C5x still w/ vlan tag → C5x removes vlan X from egress/outgoing eth1 traffic → customer

Disclaimers: By “adding” vlan technically we are changing vlan from 1 to X. Same goes for removing, we are changing from vlan X to vlan 1. I used eth1 as C5x’s ethernet port

Ok, well I am doing that right now. I have a trunk port to my A5c, in the picture I am assigning one VLAN to each CPE to untag it and send the untagged traffic to my customer’s router which doesn’t know anything about VLANs.

Customer untagged traffic → Ethernet Port on C5# → Tag at the C5# → Wireless link → A5/A5c → Trunked VLANs over the Ethernet Port → Switch → Router

CPE Data VLAN is entirely controlled on the A5c, whereas in 2.8.x it looks like there is more control on the C5# device. You also have the ability to set VLANs to exit to the customer still tagged (sorta kinda doable in 2.5.4 and previous firmwares if you don’t use the SSID VLAN stuff… But without any of the useful controls…)

Just want to report with “glee” that Firmware 2.5.4 populates the GPS co-ordinates of the AP in the CPE.
No more having to log into each radio and add the GPS co-ordinates manually.

1 Like

To be clear William5 are you referring to this area under “SSID” and when you edit the SSID choose trunk here:

Screen Shot 2021-02-11 at 9.40.37 AM

As I understood this - each CPE device had to be “tagged” ?

Or does this give you the ability to set a VLAN for each CPE behind the antenna? So no tag on the far end?

Hi all,

Unfortunately, the A5/A5c will not have 2.8.X firmware in the near future.

These are my SSID settings:
I trunk ~50 VLANs to each of my A5c radios, then each C5# I connect to the A5c gets a VLAN that it (and only it) untags for the customer. One VLAN per customer, although I guess you could probably have multiple people on the same VLAN.

Firmware version 2.5.4 for PTMP only?
Can I install C5C for PTP?


The PTP and PTMP firmwares have been unified for quite a while now, so it doesn’t matter which you use, I don’t think you even have to unlock the C5c for PTP anymore, but I may be wrong about that.

Either way, I would recommend using 2.8.0.x because it has quite a few features that 2.5.4 doesn’t/won’t have.

Really 2.5.4 is focused on PTMP stuff and I know I didn’t test 2.5.4 on any of my C5c/C5x PTP links…

Wow - in my testing / reaching out to support I was told each C5# would need a router behind it tagging traffic. I did give it a shot but could not get it working. Looks like I will need to try again!

For your IP schema do your wireless devices all have IPs on vlan 1 for management or do you use a separate management vlan? Could you post your ethernet config? Thx!