Netgear EX6120 OpenWrt support (#P25)
Looks like I missed a post last week…ah well, here it is.
From the bunch of defective hardware that I bought back in March there’s still some repaired access points left. One of the hobbyists that was interested in some EX3700 APs asked about the EX6120 that are more abundant, faster, and not much more expensive. He’s going to revamp his WiFi and wanted some OpenWrt mesh. Well…back then the hardware compatibility list said it was somewhat compatible, because both are closely related and the EX3700 has support. The EX6120 firmware was linked to the EX3700. I tried for him, actually my first experience with OpenWrt.
They’re wrong. I mean they are somewhat related, but the hardware is different enough (1×1 vs 2×2 and a different chipset) to not accept the EX3700 image and work to specification. The OpenWrt images are slimmed down quite a bit and only fit the target hardware.
At the time, I sold him all the EX3700 and one EX6120 for testing purposes. And while selling others on eBay, I came across one AP that had some problem with pushing its captive page for initial setup through. That was two weeks ago and I was intrigued if I could add OpenWrt support.
Turns out: Yes, I can. But I don’t have to do the difficult parts of it, e.g. finding hardware IDs buried in the 4MB image file. Several others tried before but gave up on the final step. The AP was fully working with a set of configuration data from the indeed very similar EX6130 (EX6120 + feed-through mains plug), but nobody managed to get this configuration pushed to the OpenWrt main repository. There’s some dude there playing the warden of good code and exact compliance to formal guidelines, and he cares more about everything being perfect from the start (“nobody touches this anymore once it’s in the repo”) than about adding support for more devices or keeping willing supporters happy.
Meet Bzzz the Physicist.
I’ve done this crap before, and I’ve actually been talking about that time with a new co-worker that has the same background. We had this drill of a six course practical training in our Master’s degree where teams of two students would measure important physical concepts on their own, e.g. the resistance quantization caused by the Quantum Hall Effect. These experiments come in pairs, you are expected to finish one per week, turn in your 10 page report and run the next experiment after passing a colloquium of 30-90 minutes about the subject and the experimental setup that you have never seen in person before. You’ll get the report back asap and it needs to be “perfect” on the second submission. If even one of the two papers is not accepted, you fail both experiments and need to try again next semester. So stuff piles up quickly and your supervisors are incredible dicks about everything from color coding ten data sources in one graph to multilevel data correction precision and methods, basically like peer reviewers in a journal – only that they hit once per week and you’re out if one of them finds something that isn’t done to their liking. I don’t think many students fail their entire degree because of this (there’s a smaller version at the start of the Bachelor’s degree measuring basic properties like the speed of light or surface tension of soapy water), but it is certainly the most time-consuming thing of the entire degree except for the thesis…which spans over 1 year+, not mere weeks. These experiments are easily 70 hour work weeks during semester breaks.
BS like this is why people hire us for frustration tolerance. BS like this is why I can switch to being a dick myself when someone acts like one and tries to break me with formal nonsense and arbitrary rules. I can put up with A LOT. This dude on the OpenWrt main repo has finally met a worthy opponent.
Please check the submission guidelines yourself.
I’m fine with formal guidelines for a large project, that’s part of why it works. But these are ridiculous.
commit subject [this is the first line of the git submission, not the pull request that is also necessary to get this into the repo]
must have a prefix that depends from what you are doing in the commit
kernel: for kernel and kmod (kernel module) packages
package name: for packages
device architecture: for devices (for example, mvebu: or ramips: add support to example_eval board )
tool name: for tools
build: for general buildsystem changes that are not targeted at something in /toolchain
must be less than 50 characters long
must describe what the commit changes and why the commit is necessary.
It is challenging to be both succinct and descriptive, but that is what a well-written summary should do
don’t capitalize first word after the prefix
don’t write a full stop at the end of the subject line
Write a well-written summary in 50 characters minus an up-to 22 character prefix minus the manufacturer and product name, don’t capitalize the first word after the prefix, and don’t you fucking dare typing a full stop at the end. Goodness gracious.
must have less than 75 characters per line
it will be committed to the source changelog, so it should explain to a competent reader why you made this commit.
Include symptoms of the failure you are fixing (log messages, error messages, etc.), it will be useful for
people searching the commit logs looking for a fix for their issue.
If a patch fixes a compile failure, include only the most relevant part of the failure log
If you add support for new hardware: Include in your commit message a short description of the hardware and how to install OpenWrt on it. Have a look at the recent additions for some examples.
all commits must contain Signed-off-by: My Name
where you write your real name and real email address, in accordance with Section 11 of the Linux Kernel patches guide.
the Author field must match the “Signed-off-by:” line
if you are editing files and committing through GitHub, you must write your real name in the “Name” field in GitHub settings and the email used in the “Signed-off-by:” must be your primary github email
if you are editing files and committing on your local PC, set your name and email with…
The rest of the commit description can be 75 characters per line and must contain vital information in a formal language. For example I needed to include not only hardware specification that is already on their wiki, but also installation guidelines – for a piece of software that installs on this piece of hardware just like software installs on literally hundreds of other supported devices. All in the wiki, probably because there’s a reason installation is described only once in full detail for everybody to see. btw, this doesn’t work with the web interface of GitHub at all, don’t waste your time – you need to do this on a local machine, otherwise you cannot fulfil formal requirements.
Best of all: Patches cannot be sent with your nick name or arbitrary mail addresses. They fucking require you to use your real name (didn’t check my ID, though…) and a mail address to their liking. I went ahead with DontFuckingSpamMe@thisdomain – rejected due to noncompliance with rule #12, “Be nice to each other.”. Boo-hoo, it’s SO offensive (yeah, that’s more spam for MY inbox, not yours!)
I think we agreed on GoodLuckReachingMeThroughThisPublicMailAddressThatIsSpamInfestedLiterallyMinutesAfterCommittingToTheGitHubs@thisdomain…
Oh, and while I was patching around things and merging multiple commits into one (which didn’t really work for me), I was also required to fix LED patterns. The device has four different LED locations and some are multicolor as well. Which is a bit strange, because the EX6130 that is, again, basically identical except for the mains plug, was accepted with this LED pattern. So if they were “wrong” on the EX6130 they are now diverging, and given “nobody would work on them” that would mean nobody would match those two except for people that actually have the physical hardware and know they’re identical. Multiple changes however require multiple commits, which cannot be processed in one push request. And of course both original and requested pattern do not match the stock firmware, e.g. I’ve repaired quite a few of these and I’ve never seen the red LED being on. Even a full boot failure only yields a blinking amber LED. Someone was thinking that if there’s a red LED, it must be used for something. But yeah man, if that is what you desire, I’ll deliver.
And we’re going on and on. Please test this patch again (sure Jim, compiling the entire thing for a new LED pattern from scratch costs me 3 hours on my high end machine), please change this, please rename this for more confusion, please do this. Dude gave me shit for things an experienced git person (e.g. one that supervises a major git repo?) could do in literal minutes, but cost me days to either fully figure out or do in some fashion that was not up to standards. He also spent hours in describing what to do, except for describing what actually needs to be done. He enjoys berating people in a way that wastes the time of everyone involved, doesn’t get anything done, and pisses volunteers off. I bet he had a blast and expected me to ghost this pull request.
Well, as I said, I can endure this. Several others gave up in bringing the EX6120 compatibility patch into the OpenWrt repo because of this nonsense. I finally broke him, he quickly did the remaining “required” things partially himself (and skipped the rest) and posted this:
Since this PR is incomplete (missing board.d/mt7620.mk) and has other issues, and I also have lost faith that our discussion will lead somewhere, I’ve put together a proper patch
Well done man, well done. You’ve not only convinced me to never ever contribute to OpenWrt again unless you’ve moved on, but also denied potentially thousands of people hardware support that could have arrived almost a year ago. A pure ego trip in allowing only the finest of commits (you know, hand crafted by naked virgins on a full moon) into the precious repository. All that effort for a mere +88 -18 patch.
Interestingly, the patch for the EX6130 was also delayed by him, as it was submitted late July 2019 and finally committed early November (you know, with a perfectly broken LED config).
What a dick. But it’s done!
I would expect mainline support for the EX6120 within 6 to 8 weeks based on current release cycles. Those snapshot files do not include the web UI (LuCI) but this can probably be added via CLI after setup, see the wiki for details. The mainline comes with the full web interface and a frozen code base, so there will be a known stable image with version 19.07.4 (?).