The older v21.02.0 build for V1 is still there as well, but what you'll now want is to enter the folder that refers to the latest version (which currently is joowin-wr758ac-v21.02.1). Upon entering there, you'll see a folder with the build for V1 variant of the device, and a folder with the build for V2. Enter the folder corresponding to your device and download the *-squashfs-sysupgrade.bin image (the other files shouldn't be needed unless you are an advanced user, need to troubleshoot something or know how to use to use the imagebuilder and want to create a custom image without having to recompile everything).
Please note: if you are upgrading directly from my previous v21.02.0 build, which was made only thinking of the device I have and didn't account for existing both V1 and V2 device variants, then when upgrading you'll get a compatibility warning of sorts. That shouldn't be problematic, it's only because I've changed the name of each image to also have a v1 or v2 suffix, so you should be able to safely check the option to "force upgrade" and still retain your previous configuration without problems (it worked for me with V1, I don't see any reason not to work on V2 but please test; to prepare for a worst case scenario, first do a backup of the configuration in case you need to reflash as when you first installed openwrt on the device via TFTP, so that you can conveniently restore the configuration, but I'm confident no one should need to get to that point).
A note for who wasn't reading all messages on the thread: if you think you have V1 but don't see the 5GHz wifi radio, then you have the V2 variant (despite what your device label may say...) and should use the other image for your device.
If the new images work fine for everybody, I'll make a pull request on OpenWRT git.
Seems like I messed up when building. I'm still adapting to building based on the official release config (to keep compatibility with the packages on the repos so that opkg install works for everything) without having to build every target...
I think I got it now, and uploaded new build to the same place. Can you check @derAuge and @elmismo ?
Sorry, I didn't understand. Are you trying to use it as a repeater and it is failing connecting (as a client) via 5 Ghz to one router, but working with another? If so, I'd say to try to change the country of the 5GHz radio to something that is less limited in terms of channels (like Taiwan or Venezuela), or configure your router to use another channel. I can't help much further there, because if it works with one device and not another, this could also be a driver issue... which would be a worst case, best bet in that case would be to open an issue on mt76 github
Hi. The MAC address is ok and the leds are ok.
I have the two repeaters, one of the version 1 and other of the version 2.
I'll try the new version tomorrow.
Thanks.
The software appears to be ok but i have a question, why the configuration of the internal vlan's are different that in the stock firmware?
The stock firmware VLAN's definition:
I can't tell why the definitions on the stock firmware are that way. Maybe they just don't use that and left it with some crazy defaults?
All I know is that I experimented with the device until I found out which was the port where traffic flowed when it had the cable connected, and that was port 4. Since the device only has 1 port, it wouldn't make sense to show other ports (although the chip itself supports 5, it's just that this device and the board only have 1 physical port soldered), so in the part that creates the switch I only include port 4 (besides the logical port that allows the CPU to see and process the traffic, which is always-tagged port 6).
Later I'll submit this pull request, hopefully the real openwrt devs will suggest corrections to anything that may not be fully correct.
Hi. I read your post and i think it's possible to update the repeater firmware through its own configuration menu, not neccesary through the tftp server. In this manner may be less difficult for the users.
Thanks.
I tried upgrading directly from the original firmware, but didn't work very well. I got stuck on luci without knowing the root password, since the upgrade retained the manufacturer's firmware settings, and since they are using a modified openwrt, that includes their default root password that no one knows.
So yeah, one possibility would be to tell people to pick up the original firmware, modify it with that set of tools mentioned somewhere at the beginning of the thread, then flash it back on the device, to upgrade to openwrt where you can login but must reset the configuration if you want to ensure it's sane...
Correct me if I'm wrong, but if I'm right then I'd rather recommend people to setup a tftp server, which is something very trivial these days
Anyway, anyone please feel free to create the wiki page for the device and put there all this info as you find best
Heads up: the pull request needed some tweaks asked by the openwrt staff. I was finally able to make them yesterday, but the pull request is still under review. Hopefully won't take long.
Meanwhile I've refreshed the content of the pre-compiled images in my google drive, reflecting the changes that are now in the pull request. If anyone can test them, to further ensure reliability, it would be nice. Thanks and I hope this will be useful. Enjoy.
UPDATE (2022/01/08): pull request was accepted in master version:
I now wonder if it will be possible for it to be also included in stable 20.02 branch, since it also works there (my builds were always based on that branch), I will try to see that.
Congratulations and thanks to everyone in this topic, you made it possible
Good day, maybe you can help...
Do you know how to restore my device, I updated the firmware and now the repeater is dead, when I plug it in, only one middle blue light is on for 10 seconds and after all three lights are switched off.
Also there are no one any network (no 2G, no 5g) the repeater shows...
So, if anybody knows how to restore the repeater - please let me know!
But it seems to me that you are trying to put a file via a tftp client? That's not how it works.
Your PC, which acts as the server, must have the IP 192.168.1.10 netmask 255.255.255.0. The firmware_auto.bin must be in the root of the tftp server (be sure to specify the correct folder in the tftp server program). Also temporarily turn off windows firewall to ensure it does not block the incoming connection (it's the AP that tries to connect to your PC, not the other way).
Then turn off the AP, and plug it to the same network, via ethernet cable (I suggest a direct connection to the PC ethernet port ensure your not hitting other problems).
Now when you turn it on, it will make a GET request to 192.168.1.10 for the bin file (no need to press any button), and after successful transfer it will flash it and reboot with the default configuration for that firmware.
I usually use Linux with dnsmasq, never tried on windows, but assuming your configuration equivalent to what I explained, it has to work - unless something happened to the u-boot partition of the AP... which is nigh impossible with regular openwrt flashing using luci...
Please revise the configuration as I said above and try again, or use a different tftp server (not client) tool.
