Category: Troubleshooting

  • MIKROTIK hAP ax S Wifi running extremely slow on Thinkpad T480 [SOLVED]

    MIKROTIK hAP ax S Wifi running extremely slow on Thinkpad T480 [SOLVED]

    I have a Mikrotik hAP x S router configured with mostly default settings. I noticed wifi was running extremely slow on the default network. I first tested the network while plugged straight into the router and saw more or less what I expected – a 500Mbps download speed from my carrier.

    Testing the wifi connection was a different story. I was only achieving a maximum download speed of 3Mbps.

    I ran the following at my Debian terminal:

    06:43 PM-adam@adampc:~$ iw dev wlp3s0 link
    Connected to d0:ea:11:13:af:b7 (on wlp3s0)
           SSID: MikroTik-13AFB7
           freq: 2462
           RX: 16009177 bytes (20247 packets)
           TX: 32704312 bytes (30902 packets)
           signal: -41 dBm
           rx bitrate: 6.0 MBit/s
           tx bitrate: 300.0 MBit/s MCS 15 40MHz short GI

           bss flags:      short-preamble short-slot-time
           dtim period:    1
           beacon int:     100

    This revealed a healthy TX rate but an absolutely abhorrent RX rate.

    After a lot of troubleshooting I discovered both the 2.4 and 5Ghz bands were sharing the same SSID.

    The immediate solution is to simply put the 2 bands on different SSIDs.

    wifi–>interface–>wifi1 allows you to change the SSID for the 2.4Ghz network.

    Why this fixes the problem:

    When both the 2.4 GHz and 5 GHz radios share the same SSID, your laptop (and most Wi-Fi clients on Linux in particular) has to decide which band to attach to using its own internal logic. That decision is not always optimal.

    In my case, the ThinkPad T480 consistently chose the 2.4 GHz network, even though a faster 5 GHz network was available. This is a common behavior because:

    • The 2.4 GHz signal often appears “stronger” or more stable at first scan
    • Linux Wi-Fi clients tend to be “sticky” and do not aggressively roam to better bands
    • The access point’s band steering (if present) is not strong enough to override the client decision

    Once connected to 2.4 GHz, performance was severely limited due to:

    • Heavy local congestion from neighboring networks
    • Narrow channel bandwidth
    • Legacy Wi-Fi rate fallback behavior

    This resulted in the Wi-Fi link negotiating a 6 Mbps receive rate, even though signal strength was excellent. That single factor explains the observed ~2–3 Mbps real-world throughput.


    The key insight

    The issue was not raw signal strength or ISP bandwidth. It was that:

    The device was correctly connected, but on the wrong frequency band.

    Because 2.4 GHz is shared, crowded, and prone to legacy rate fallback, even a “good signal” connection can perform extremely poorly.


    Why separating SSIDs works

    By splitting the network into:

    • MikroTik-2G
    • MikroTik-5G

    you remove ambiguity. The client is now forced to make an explicit choice rather than an automatic one.

    This has several effects:

    • The 5 GHz network becomes directly selectable and predictable
    • The client stops defaulting to 2.4 GHz “by accident”
    • Roaming behavior becomes deterministic instead of heuristic
    • The high-speed band is consistently used for throughput-heavy traffic

    Final outcome

    After separating the SSIDs and connecting directly to the 5 GHz network, performance immediately returned to expected levels, with significantly higher link rates and throughput aligned with the ISP connection.

    The fix confirmed that the issue was not hardware, drivers, or ISP limitations — but simply band selection behavior combined with shared SSIDs and suboptimal Wi-Fi steering.

  • Invalid file signature errors on HP G10 servers

    Invalid file signature errors on HP G10 servers

    When attempting to update individual components like the BIOS, you may receive the following error:

    The file signature is invalid. Make sure you are using a valid, signed flash file and try again.

    In my case the iLO 5 firmware was at version 1.46. You can’t easily jump from such an old version to the latest version. Old versions of iLO cannot verify the signatures of the newer BIOS/firmware packages. The solution is to simply stair step the iLO firmware to the latest release and then all the other packages should easily install.

    You also cannot jump from iLO version 1.46 all the way, to let’s say, version 3.18 at the time of this writing.

    I found the following upgrade path works.

    1.46 —> 2.14 —-> 2.35 —–>3.18

    You might also try the following but it fails for me sometimes depending on the server:

    1.46 —>2.35—->3.18 etc.

    Certain version of iLO introduced capabilities to handle larger file sizes. Perhaps some servers have smaller BIOS packages hence the success of this upgrade path for some and the failure for others.

    Once the iLO is fully updated it processes the BIOS upload correctly: