Good, I also thought that 64MiB should suffice for AP.
Traditionally we use the OEM name which has made the certification, which in this case is Arista (previously Mojo), WatchGuard probably sources the devices from them. I've added the name in device recipe so if You try to use menuconfig to build firmware You'll see it there. I could also add it as model in dts so it will be visible in LuCI status page.
Yeah, it was used by OEM for monitoring surrounding area. It's ok for 2,4GHz but not so much for 5GHz when used as AP.
I didn't look at it carefully but that does not seem to impair the functioning of the interface.
Interesting that Arista define different operating modes for PoE if 802.3at is not available. I wonder how that is handled. If it's all in software I don't imagine openwrt does anything and in that case can it try to pull too much power?
It's all in software. Look in the OEM firmware at /etc/poe_prof.cfg, there are specified GPIO pins (in our case 15 and 16) whose status shows which power source is connected. The GPIO pins show if 802.3af or 802.3at or DC is used. Then the /sbin/8023af.sh according to that config, checks and regulates which functions to turn on or off. It switches WiFi chainmask and output power, USB presence, and even manages presence of second ethernet port.
In OpenWrt none of that is handled. I decided to disable only USB by default, but maybe I should also disable second ethernet port? I should probably state in commit message Notes section, that powering the AP with DC or 802.3at power source is recommended.
Hmm, disabling the port seems like it would be confusing for users. Probably best to just document the issue as you say. It would be interesting to know how it fails if you try to use too many things on .af
I will say it grates on me that Access Point devices still come up in a 'router' configuration when OpenWrt first boots. The number of times I've managed to bring down my test network because OpenWrt took over DHCP duties with the default subnet. More of an issue if your AP is screwed to a ceiling somewhere when you upgrade it. But I understand why it's done.
I would say, with the amount of features the AP provides 20 W should be bare minimum (the DCs 24 W looks ok), which .af doesn't provide. I think the AP would run with .af with all features enabled but either stability or longevity would suffer, or both.
You don't save the configuration on upgrade? Sometimes the upgrade introduces breaking changes but that rarely happens.
I decided to set the PoE+ port as WAN because of vendor default configuration and the LED pictogram looks like globe . Of course that's for the debate and we can change that, until it lands in main tree.
I was looking for the GPIOs that controls them to no avail, until it occurred to me they might be connected to PHYs.
The initramfs ramdisk defaults to half your system RAM.
I have found in previous PRs that OpenWrt developers prefer if you allocate as much flash as possible to OpenWrt. Is it not possible to restore this device writing the original vendor image via tftpboot in U-Boot?
Usually installation instructions include backup/restoration instructions in lieu of leaving the original OS image on the device as a backup.
No. There are no unencrytped images available, so the only way to go back is keeping the second firmware slot intact. I don't know how it is with scenarios where there's controller involved (some Firebox firewall), so I'm inclined to keep the second slot.
More of an issue if your AP is screwed to a ceiling somewhere when you upgrade it. But I understand why it's done.
. Of course that's for the debate and we can change that, until it lands in main tree.