Package Details: winbox 4.0beta12-1

Git Clone URL: https://aur.archlinux.org/winbox.git (read-only, click to copy)
Package Base: winbox
Description: Mikrotik RouterOS GUI Configurator
Upstream URL: https://mikrotik.com/download
Licenses: custom
Submitter: TomHetmer
Maintainer: dundee (eworm)
Last Packager: eworm
Votes: 63
Popularity: 3.69
First Submitted: 2013-05-11 20:19 (UTC)
Last Updated: 2024-11-20 13:54 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

juliusv commented on 2024-01-22 19:03 (UTC)

For configuring HiDPI run:

WINEPREFIX=$HOME/.winbox/wine /usr/bin/winecfg

and change the "Screen resolution dpi" setting found in the "Graphics" tab

theoratkin commented on 2023-11-02 16:11 (UTC)

Would someone mind explaining the versioning to me? This package is 3.40, but on the website, all I see are 6.x/7.x. Thanks.

6.x/7.x are RouterOS versions, not WinBox. If you click the WinBox dropdown on this page, you will see WinBox 3.40 downloads for x64 and x86_64.

Omar007 commented on 2023-10-25 11:03 (UTC)

After the one time it had the checksum on the PKGBUILD of 3.40-1 it flipped back (to what turns out to be the right one then). Checking again right now, it's still incredibly slow/unstable to download but the checksum has, aside from that one time, always ended up as 91f7b0456619dbfc19940a85566c949ce3718321f32709886df5125c71f0b6b7.

It's good to have confirmation which one is supposed to be the right one (they should really have this on their website or forum release posts honestly...). Now it's not really a gamble any more whether we'd be running something invalid or not.

tekeous commented on 2023-10-24 05:27 (UTC) (edited on 2023-10-24 05:28 (UTC) by tekeous)

FWIW, I have been able to reproduce the issue where it throws ERROR: One or more files did not pass the validity check!. I am using yay on EndeavourOS and have been able to delete ~/.cache/yay/winbox and it works the second time, every time. I'm not sure it's a Mikrotik issue, or it would not work so reliably after wiping cache.

Also, this issue reoccurred at 10:00PM PST 10/23, so Mikrotik's fix as of 10/20(previous comment) was either not successful or not present in latest version.

abruegmann commented on 2023-10-20 11:25 (UTC)

I've contacted Mikrotik and they've fixed the issue:

Thank you for the report.
We've found and fixed the issue.
Please verify if you now receive the accurate value:  91f7b0456619dbfc19940a85566c949ce3718321f32709886df5125c71f0b6b7  

Omar007 commented on 2023-10-19 19:55 (UTC)

Tried again and after 6 times of the MikroTik server interrupting/terminating the connection, it finally finished the dload and it had the checksum in the PKGBUILD this time.

Omar007 commented on 2023-10-19 14:09 (UTC)

Well yes, but that's basically saying --yes-i-will-take-this-corrupted-or-virus-invested-file. A checksum mismatch is not something to blindly ignore. And in this case it's not like we can look at the source changes or something.

In general it's weird for there to be different checksums for different people for the same file. That means something is wrong. Whether that is of a malicious cause or not is a different question.

I've grabbed the file again today and it's still the other checksum instead of the one in the PKGBUILD (and also still very slow...).
It would be nice if someone that had the checksum in the PKGBUILD download the binary again and check if it switched to the other checksum or not. If yes, maybe MikroTik replaced it after the initial upload. If not, there might be a regional server/cdn issue or something.

loxothrone commented on 2023-10-18 18:55 (UTC)

you can always skip hash cheking by using makepkg --skipinteg -si PKGBUILD

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »