Open AiyionPrime opened 2 years ago
I will take care of d-link-dap-1330-rev-a1
and d-link-dir-505-rev-a1
(maybe also a2
if I happen to find a unit within my pile, though I believe they are identical except for the exchangeable mains plug).
What happened to DIR-825 B1? It should still have sufficient memory and is supported in OpenWrt ath79, maybe I can still find a unit as well.
@s-2 I'll add your efforts to the list above, once you drafted the PRs for the respective devices.
Regarding DIR-825 B1, it's has only 6M for firmware and has been marked as tiny before in https://github.com/freifunk-gluon/gluon/commit/cfce3ee91e17708df44331b45f7b80cb6256b458.
Feel free to try, but tiny is out of scope for this tracker, as I wrote above.
I can also take care of the tp-link-archer-c7-v2.
I can also take care of the tp-link-archer-c7-v2.
i have it nearly finished, just waiting for a new build to finish because i was missing to add the wifi driver and if that works i post the PR.
Hi @AiyionPrime , I got your DM on https://forum.freifunk.net/, feel free to use my github account @heis2201.
I am happy to contribute by testing the migration process, however, I need to find some spare time and I have to figure out how to flash the OEM firmware back onto the tp-link-tl-wdr3500-v1.
Is there is chance I can brick the device to a state where recovery is impossible? Did I get this right that test migration of each device is documented in a separate issue here on github?
Cheers
@AiyionPrime what does "wants to test" in your list mean? the text above suggests that this person intends to create a PR, which is not the same as testing something. i don't have the time to create PRs for all the devices mentioning my name. also, i don't have a C59 and a wr1043v5 at the moment to test, but i have a ubiquiti-unifi-ac-lr also note, ubiquiti-unifi-ac-mesh is no separate device but an alias, as far as i know.
also note, ubiquiti-unifi-ac-mesh is no separate device but an alias, as far as i know.
It's a separate device in ath79. As no dynamic model detection exists anymore, even completely identical devices get separate images, so each can show the correct model name.
Hi @AiyionPrime , I got your DM on https://forum.freifunk.net/, feel free to use my github account @heis2201.
Nice, I'll update the list accordingly.
I am happy to contribute by testing the migration process, however, I need to find some spare time and I have to figure out how to flash the OEM firmware back onto the tp-link-tl-wdr3500-v1.
Is there is chance I can brick the device to a state where recovery is impossible?
The OpenWrt page is worth a visit, when it comes to sharing experiences with flashing in various directions. While it should not happen, it's technically possible to brick your device. Most devices do have some form of recovery though, which OpenWrt (and therefore gluon as well) aim not to overwrite.
If you are uncomfortable doing the testing alone, you can always ask for help in hackint#gluon, there are enough people who have done the same process before.
Did I get this right that test migration of each device is documented in a separate issue here on github?
That I try to open a seperate PR for every device I add helps me to stay on top of what I'm doing, when I work on five different devices. There's no rule you cannot do more that one device at once, which @ecsv impressively demonstrated a week ago :D It just keeps things simple.
@AiyionPrime what does "wants to test" in your list mean? the text above suggests that this person intends to create a PR, which is not the same as testing something. i don't have the time to create PRs for all the devices mentioning my name. also, i don't have a C59 and a wr1043v5 at the moment to test, but i have a ubiquiti-unifi-ac-lr also note, ubiquiti-unifi-ac-mesh is no separate device but an alias, as far as i know.
The list does contain every device or alias we'd possibly intend to migrate to ath79. That I added aliases as well just helps to see which aliases must not be forgotten at first glance. And gives ideas like "didnt these x revisions of that device all have the same hardware".
"Wants to test" is a mere reference, someone has ever announced interest in supporting the migration process for that particular device. The list is not endless; when you have time to do a migration on your own that's great. And when there's someone that "just" owns a device and would like to help I think that's worth a lot as well.
I currently have a break after my exams, so whoever has a device listed in "todo" above and cannot do the migration on his own, I'm happy to assist. That might not be enough in all cases, but should be sufficient for first time contributors like @heis2201.
And if you have no time to prepare the PRs, get me a list of a few devices you'd like to "just test" and I'll build the images for you as well.
OK, I'm happy doing some testing over the next few days. Where can I see a list of test cases? Has anyone assembled a guide or at least recommends an order of doing things. Haven't spend any time thinking about it, but right now I would say, I test the migration from ar71xx to ath79 using sysupgrade
, and in a second test I flash the OEM image and then flash the ath79 factory
image. More or less correct?
The list you are looking for would be https://github.com/freifunk-gluon/gluon/wiki/Device-Integration-checklist .
The order depends on whether you've got stock or ar71xx firmware on your device. But looking at the list, you'll figure that out.
Have you built gluon before? And looking at recently closed PRs, do you want to do the PR on your own?
I have never built gluon myself. How hard is that - where do I find documentation and requirements about it? is there some build infrastructure I could use, or do I build this locally?
I am happy to do the PR on my own.
https://gluon.readthedocs.io/en/latest/user/getting_started.html#building-the-images
That's a good point to start from. You'd build it locally, building gluon from scratch costs me about an hour on my 2013 laptop. Rebuilding is faster.
Then good luck with it :)
Where would I find the container that is mentioned in the docs? Otherwise I would have to spin up and update a Debian VM first, which would take much longer.
Also, what the the RELEASE
? v2021.1.1
? Next, what would be my site configuration? The one from my regional freifunk community?
This thing is a bit bigger than I was hoping for.
Should I stop my support questons here, and we continue the conversation elsewhere (freifunk forum for example)?
If you want I'm available in hackint#gluon. You could join via webchat, that should be the fastest way.
https://webirc.hackint.org/#irc://irc.hackint.org/#gluon
We do support matrix as well: https://matrix.to/#/#gluon:hackint.org
I have an IRC client and a matrix account, but I am afraid this would be something I would do late night, and rather spontaneous. But will see, once I get to it, I will be in touch
I can offer to test a ubiquiti-unifi-ac-mesh-pro. Will be this WE earliest though.
sagt mal das target lautet ath79-generic oder ath79-nand ?
Kommt auf das Gerät an. Die erste Spalte der Tabelle gibt an, in welchem der beiden Subtargets das Gerät in ar71xx war.
Die Geräte, die du erarbeiten wolltest, scheinen generic zu sein.
The "ubiquiti-unifi-ac-lite-mesh" is not thing. Goal is 118 now.
I can offer to test a ubiquiti-unifi-ac-mesh-pro. Will be this WE earliest though.
@udoschneider earlier in this thread
Looking at recently closed PRs, you might find enough inspiration to do the PR on your own. Let me know, if you'd like to avoid building gluon yourself and would rather "just" flash and test the device; in which case I'd offer to provide the PR for you.
Looking at recently closed PRs, you might find enough inspiration to do the PR on your own. Let me know, if you'd like to avoid building gluon yourself and would rather "just" flash and test the device; in which case I'd offer to provide the PR for you.
If you have a ready to flash firmware I'd happy to try this now. I'm able to build gluon using the ffmuc site but don't understand the build process enough to guarantee I'm building the correct branch.
I will notify you when it's built. ETA 35m.
@udoschneider https://github.com/freifunk-gluon/gluon/pull/2462
Gestern Abend war das zweite Entwickler-Meeting diesen Jahres.
In Anlehnung an das Gespräch ergeben sich in der Liste oben zwei Änderungen.
Zum einen wurde mir der Unterschied zwischen dem Target tiny
und der Device-Class tiny
aufgezeigt. Mein Ziel war es, das ar71xx-Tiny-Target in diesem PR nicht zu berücksichtigen.
Die fehlenden Geräte habe ich den Listen oben hinzugefügt.
Desweiteren haben wir einen besonderen Fokus auf Geräte beschlossen, die laut Multi-Meshviewer mehr als hundert mal betrieben werden.
Diese Geräte von besonderer Dringlichkeit sollten leichter aufzutreiben sein und mehr Sinn stiften, als der Rest und sind obig dick markiert.
Vielen Dank allerseits.
@rotanid closed the related PRs already, in todays Developer Meetup we agreed to dismiss the migration of xx/32 devices. That's not all of device-class tiny, but a significant ease on this issue.
That's not meant to be understood as "we don't want Gluon to support them", but merely none of of us is currently willing to put the necessary effort into these devices to get them running on a recent kernel again.
@NeoRaider suggested, someone willing could test an ath79-tiny approach. But that's not my intention to track here, as long as no one stepped up to get them working again.
@rotanid closed the related PRs already, in todays Developer Meetup we agreed to dismiss the migration of xx/32 devices. That's not all of device-class tiny, but a significant ease on this issue.
That's not meant to be understood as "we don't want Gluon to support them", but merely none of of us is currently willing to put the necessary effort into these devices to get them running on a recent kernel again.
@NeoRaider suggested, someone willing could test an ath79-tiny approach. But that's not my intention to track here, as long as no one stepped up to get them working again.
Hello @rotanid and @NeoRaider, Just to be sure about some specific 8/32 devices, since I have several TL-WR710N v1.2 and v2.1 running Freifunk München and other community images. You are saying these WR710N's won't have a future, unless somebody will develop an ath79-tiny approach, even though they support OpenWrt 21.02.3 ? Is somebody aware of any work having started on this approach? Thanks very much!
Hello @rotanid and @NeoRaider, Just to be sure about some specific 8/32 devices, since I have several TL-WR710N v1.2 and v2.1 running Freifunk München and other community images. You are saying these WR710N's won't have a future, unless somebody will develop an ath79-tiny approach, even though they support OpenWrt 21.02.3 ?
Yes, like every device with less than 64M memory. we tested many things and didn't achieve a usable image.
as a sidenote, OpenWrt 21.02 is not relevant as Gluon v2022.1 will be based on OpenWrt 22.03.
Is somebody aware of any work having started on this approach?
no to my knowledge
You are saying these WR710N's won't have a future, unless somebody will develop an ath79-tiny approach, even though they support OpenWrt 21.02.3 ?
What is Important to note here (As it is missing) is the fact a -tiny approach would only delay the inevitable by ~1 year. Thus nobody at the developer meetups was interested in such a non-longterm solution.
LAST CALL - diese Geräte werden sonst im Release fehlen!
es gibt an die 200 Geräte die in den Communities online sind, die genug Speicher/RAM haben aber wo uns Tester und/oder Testgeräte fehlen, z.B. folgende. (alle die öfter als 10 mal vorkommen) Bitte dringend bei uns melden!
Ubiquiti UniFi AC MESH PRO
Ubiquiti Rocket M2
AVM Fritz!WLAN Repeater 300E
Netgear WNDR3700v4
Netgear WNDR3800
Ocedo Koala
TP-Link TL-WR2543N
am stärksten betroffen werden sein: Münsterland, Stuttgart, Nordheide
Redacted
- p-link-cpe220-v1
- tp-link-cpe220-v1.1
- tp-link-cpe520-v1.1
Oben steht "never sold", Wir haben diese sehr häufig in Kiel und Nord, daher klingt die beunruhigend. gibt es dazu schon nähere Erläuterungen irgendwo?
@rubo77 Auf den Karten von Kiel und Nord kann ich nur CPE210 entdecken, keine CPE220 oder 520.
- p-link-cpe220-v1
- tp-link-cpe220-v1.1
- tp-link-cpe520-v1.1
Oben steht "never sold", Wir haben diese sehr häufig in Kiel und Nord, daher klingt die beunruhigend. gibt es dazu schon nähere Erläuterungen irgendwo?
Wenn du wirklich irgendwo eine 520er oder 220er hast, baue ich dir alle Images, die du brauchst. Sicher, dass das keine 10er sind?
Stimmt, verkuckt. Die Kommentare können alle wieder weg
@heini66 kann ein paar geräte bereitstellen, (kontaktiert ihn bitte in matrix)
Wir haben in Chemnitz auch mindestens eine CPE 220. Da kann ich das mal testen.
@ambassador86 Mhm, gerne. Aber ihr habt da nicht 'auch' eine CPE220. Ihr hättet die erste und einzige, die wir im Migrationsprozess gesehen hätten.
@heini66 kann ein paar geräte bereitstellen, (kontaktiert ihn bitte in matrix)
@rubo77 Wenn du ihm schon gesagt hast, dass wir das so rum machen, von mir aus.
Generell würde ich mich freuen, wenn die Leute, die wollen, dass man Ihnen bei der Migration ihrer Geräte unter die Arme greift selber ein bisschen Initiative zeigen. hier irgendwas über Berge und Propheten einfügen
@AiyionPrime sogar im OpenWRT Wiki steht drin, dass die Dinger von Varia verkauft werden. Und die sitzen hier bei uns.
@AiyionPrime sogar im OpenWRT Wiki steht drin, dass die Dinger von Varia verkauft werden. Und die sitzen hier bei uns.
Wenn die sich anfinden, sehr gerne. Wollte nur vermeiden, dass du deine Zeit verschwendest, falls du auch einen Zahlendreher gehabt hättest. Bin optimistisch gespannt.
@heini66 kann ein paar geräte bereitstellen, (kontaktiert ihn bitte in matrix)
Ist angeschrieben.
@rubo77 okay. Seine Geräte waren zwei, die bereits im Bereich "done" stehen. Das hat sich damit auch erledigt.
@AiyionPrime ich hab naturlich nicht richtig hingeschaut und es sind beide v3 daher kann die v1 vermutlich raus, wenn sich keine anfindet.
As of our meetup today, we'd like to remove this effort from the roadmap, as we are mostly done and this issue is becoming more and more stale. We do not intend to exclude the remaining missing devices from our codebase, but would like to revoke the prominent position this issue has been taking for months now.
Thanks to everyone involved so far - and happy hunting for the remaining "treasures" to whoever finds them.
@rotanid I unpinned the issue.
I could help by trying to contact the one device owner in Aachen of an "ubiquiti-unifiap-outdoor" (non-plus variant) for testing it. It's currently listed as "wanted to test" by yourself @AiyionPrime Do you have access yourself or is help appreciated?
We bought such a router and bricked it upon testing -.-' I ordered a SOP16 clip to flashback the image I dumped before.
But until it arrived in europe, someone already tried to solder around the ground pin of the chip... Until I've undone this help, I cannot test it again.
Unless you know someone who could unbrick the device in case the update really bricks routers, I'd be hesitant to accept help :/
I won't get to it until april due to exams.
that sucks 😣 I'll refrain from offering help. If there's a chance to brick, then I won't try to convince anyone to let us test new fw on their device. It doesn't make any sense to brick more devices that are in "production" and working.
@AiyionPrime I have a NBG6716 to test some images. Currently running stock ath79. I'm happy to try things out. (But I'll need some guidance - By now I'm only experienced with TFTP recovery of the box 😆 ).
@techtimo That sounds great. The first step is to open a Pull-Request with changes similar to this one: https://github.com/freifunk-gluon/gluon/pull/2460/files
Clone this repo locally,
create a new branch ath79-nbg6716
and make in the same files at the same places in the files as linked above.
Replace 6616
with your 6716
and commit your changes with the message ath79: (re)add ZyXel NBG6716
.
Push your changes and we can guide you through your next steps in the PR you'll open :)
@NeoRaider's recent contribution of the network regeneration got merged (thanks to all involved!) and if I'm not mistaken, we've agreed on testing the devices that were gone again, as if we'd be adding new support for them.
That's arguably an effort, but hopefully one divided on several shoulders.
Below is a list of devices that got dropped with the target ar71xx, which hadn't been marked as tiny back then and was not within the mikrotik subtarget. I think that would be a solid start for the migration.
I'll order them in ongoing, todo and done. Please sue
ctrl+f
to find the device you are interested in.Testing the devices is not only flashing from stock and via sysupgrade, but sysupgrading from an old ar71xx image as well. You do not need to build an ar71xx image for this, as hanover has them available here and will provide you with access to its VPN infrastructure. If possible let us know when you're done with the key.
Testing will result in failures for some devices due to unhandled migrations for now.
Thanks for your help, Aiyion.
in progress
todo
@rotanid just showed me a (shorter?) list of devices to migrate, which includes tiny targets as well. I extracted the parts, where someone announced he would be willing to test the device. For now I wont update from that list on a regular basis, but just this once. If somebody wants to test a device, submit a PR draft to gluon and I'll update this accordingly. Thanks for the hint.
done
unlikely/wontfix
as tasklist for actual progress tracking
in progress
todo
done
wontfix