It's not that I don't see your point about PoE frequently being more useful on the lan side of the network, but the fact that the manufacturer chose to label the port WAN PoE isn't OpenWrt's fault. OpenWrt simply ensures that the software naming matches that of the hardware. That's all it is. If you don't like it, feel free to make a PR and plead your case to the developers who have the authority to approve/reject the PRs.
You could make an account in the Wiki and edit the ToH entry for the device to contain your information/warning. This might help prevent "new user" cases you described.
As for your own use case, I think it is reasonable to expect from you to build your own images and subsequently upgrade the devices with self-build images. That eliminates any potential issues that might stem from using "standard firmware" and therefor "bricking" devices due to (significantly) changed configs in the future.
+1. This is an excellent idea.
Notwithstanding the above, IMO, the "new user" will be more likely to expect that the labels on the device are consistent with their functions (i.e. lan port to be used for the lan, wan port for the upstream connection to the internet in a routing type configuration).
Expanding a bit as I think even more about it... I think it is relatively unlikely that a user will be confused about why the wan port isn't configured as a lan port. And, when considering initial setup via PoE, it would not be good if the port was configured as lan and then facing a PoE switch with an existing network as this could cause an address conflict (192.168.1.1 is a very common address for the main router and the DHCP server is enabled by default)... so it's actually even better for new users to need to plug in a computer into the lan port first (btw, the device can be powered by PoE on the wan and then accessed directly with a computer connected to the lan port).
The more likely scenario is that a new user who wants to use the device as a pure AP will come onto the forum asking how they can swap the ports. To your point above, notes in the wiki article would be useful to answer those questions pro-actively. @tmittelstaedt -- maybe you can contribute there.
Never said it was. In fact to clear the record right now I'll say categorically Netgear designed this device and used ass-backwards labeling on it. They are the stupid ones not OpenWRT.
Just because your friend does something stupid and jumps off a bridge is that a reason for you to do the same? Seriously, didn't your mother ever tell you that? LOL
This blind follow-the-label is only for THIS version of AP. There's OTHER different APs that OpenWRT is ported to that are the opposite. For example the MR-52 does not label the 2 ports on it LAN/WAN. But, it does label them PoE and no PoE. OpenWRT correctly uses the PoE port as the lan port. In fact, I will point out that OLDER versions of OpenWRT don't always. Sometimes in the process of flashing an MR-52 when you boot it from an older initramfs image, the ports will be swapped. It happens on some of the units, I don't know why - maybe hardware differences, whatever. But when you sysupgrade to current OpenWRT from initramfs - which as you know wipes the config - the PoE port is ALWAYS the lan port even on the ones where the older initramfs image swapped them.
You talk about submitting a PR. I am thinking of that. But not for this. I'm thinking of gathering a number of other of these weird class of AP's that are sold like the Netgear, as APs, but with 2 ports on them and testing on them to see what they do. They all seem to use the same family of qualcomm chipset with one port a Poe one a non PoE. I think it would be wise for OpenWRT to make a firm standard to anyone porting to that chipset to ignore the labeling and make the PoE port the default port in their submitted builds.
I have, of course, zero illusions that the dev team will do anything more than argue with each other over it with the devs that did it the WAC 510 way siding with you and the devs that did it the other way (on the C-75 for example) arguing with me, and that nothing will come out of my effort.
But at least the truth will be out there where it needs to be.
In the case of the MR52, since there is no lan/wan marking, it makes sense that OpenWrt would use the PoE port as a lan port. But, consistent with what I've been saying... the labeling inside OpenWrt is consistent with the labeling on the hardware.
Can you provide an example where the hardware is labeled "WAN" and the OpenWrt uses that port as a lan port???
Just to provide another example of the precedent for the PoE port being used as a wan dating back some 15+ years.... another device that defies what you believe is logical...
The RouterStation and RouterStation Pro both have PoE inputs on eth0 which is used as the wan port. They contain a 3-port switch (eth1) which is used for the lan (via br-lan).
I already have, I've already submitted plenty to the wiki for other devices, and added things to the wiki for this one. The warning was already there in any case but in the usual "cryptic UNIXese this only makes sense if you already had your ass bit by this" that unfortunately has been with UNIX documentation since UNIX first became a thing.
As for my own case, the problem is using these things in an organization. In an organization I have the bandwidth to spend a few hours arguing with you folks and making an obvious point, and digging out what's needed to workaround. But anything you use in an org MUST meet "the bus factor" That is, if I get hit by a bus, then others will have to take over and maintain what I've built. Thus it needs to be KISS wherever possible. A fundamental principle of that is NOT to choose a more complicated solution when a simpler one is available.
Ultimately it does not matter if OpenWRT continues to follow the mislabeled port on this device or not. It ONLY matters if they keep doing it THE SAME WAY in future builds. If they don't standardize on the PoE port as the LAN port - no biggie. The flashing instructions for these I use for internal org documentation will say to swap the port, and will account for this by instructing to use AC adapter port during the flashing process. If on the other hand OpenWRT does the sensible thing and switches the LAN default to the PoE port - then I can make the internal org documentation even simpler.
But I'm NOT going to add pages and pages to the internal documentation that discuss downloading the source and changing the ToH entry and building a custom build just to get an AP working because whoever follows me will most likely get 1 page into it before starting to think "this is way over my head I'll just pay Cisco or Netgear or whoever their 30 pieces of silver a year per access point and be done with it" and then BANG - all the work I did to build an inexpensive network of OpenWRT aps gets flushed down the toilet by my successor who will just authorize an additional $10k a year for "access point subscriptions" and the C-Suite will just pay it - because even if they know there's a better way (because I showed it to them) I'd be gone and my successor won't have the knowledge and experience I do to set this thing up.
The OpenWRT project is diminished by this, you have to understand. If you REALLY and truly are an OpenWRT supporter, you need to take the big picture view. The big picture view is that the EASIER and SIMPLER you make a bit of tech to use the MORE people will use it. This is why DD-WRT is probably kicking OpenWRT's ass in terms of installed base - because it's deliberately kept "keep it simple stupid" They don't have filesystem overlays and they support far more gear and all the apps are build into the firmware image and NONE of their gear they support requires people to open the AP solder on headers and hook a serial port to it.
I choose OpenWRT for org deployments because I can install SNMP on the APs and use a real Enterprise network management program like Nagios to keep an eye on them not some toy "cloud interface" cobbled together by Netgear or Meraki. DD-WRT does not have this because tiny deployments with 2 APs for their house don't want to spend time learning what SNMP is.
The reality is OpenWRT's Achillies heel is 3/4 of the people involved don't seem to understand the balance between customization and standardization and get hung up on the customization. They think "OpenWRT is so great because it's free and I can build my own image just the way I want" They don't understand that OpenWRT is so great because technically it's in a completely different universe than even what's available commercially.
The ONLY enterprise commercial AP's out there that you can actually SSH into that have real Enterprise management ability are Cisco ENTERPRISE access points not this Meraki toy cloud interface garbage Cisco pushes out to the masses. And with OpenWRT I can pick a WAC 510 out of the surplus bin at Goodwill for $6 and get an AP that exceeds even the $1200 Cisco Enterprise AP and has exactly the same CPU and radios in it that the $1200 AP does. How flipping cool is that!!! How can you all miss this!!! Holy cow, man!!!! WAKE UP WAKE UP!!!!!
1 Like
Those are routers, that's why they are named "RouterStation" Not Access Points. The WAC 510 is an Access Point that's what the A in the model name is.
For a router you can make a use case for the PoE port being WAN because Ubiquity would be of course, pitching this to ISP's and so on where the ISP might decide it's useful to set a customer up with 2 separate devices - a DSL modem or cable modem and a router, instead of a combined thing, and power the router off the DSL modem to save the $5 that a second AC adapter would cost.
It would be interesting to know if Ubiquity did succeed with this. For sure, none of the ISPs around here supply their gear. For a few years around a decade ago one of the ISP's here supplied some Netgear routers but that ended when they started supplying the combined cablemodem/router/wifiAP devices.
A useful router project would use a naming scheme consistent in time such that it's possible to swap out a vendor X router for a vendor Y router and copying the configuration with the user not knowing anything about the underlying devices.
From what I understand from OP, OpenWrt currently doesn't do that.
That seems like valid criticism.
Having said that, OpenWrt probably was never designed in the first place, was it? Is there a formal mathematical model of every API provided by OpenWrt? I doubt it. As long as there isn't, whatever OpenWrt happens to do in a given release is what it does and that's it, which as a user, and particularly as a business, is absolutely not what you want to hear.
As such it's also entirely reasonable to say "Yes, OpenWrt isn't perfect for that use case, but patches welcome". Still, in order for that to happen there should first be some kind of consensus that OP's idea is an improvement (it certainly sounds like it would be, but I don't pretend to know).
A similar thing happens with naming ports. Should a project have as an abstraction that ports are identified in increasing numeric order (1,2,3,4)? What if some crazy manufacturer were to just introduce random port mappings as a feature with no way of knowing which is which?
Part of this is that the interest of vendors is that nobody uses OpenWrt and the interest of the OpenWrt user community is that everything comes with OpenWrt support provided by the vendor.
Also, indeed, I am not an AI. 
Actually, I think that has happened already more as a result of makers not properly understanding the chipset reference designs or possibly trying to avoid patent infringement.
I think it's more complex than that because a lot of makers DO use OpenWRT as their cores they just remove Luci and put their own webinterface wrapper and then add a daemon program to OpenWRT that reports all kinds of useful marketing statistics back to their cloud motherships. (Unless of course they are Chinese. In that case, the daemon program reports back to the Chinese military, LOL)
It's kind of a "frenemy" relationship they have with OpenWRT.
I think the business perspective here is that cheap labor can "support" Meraki, even though it probably has less features than you, a networking God, made.
In a way, you also need to let go; it's not your business.
I also have designed a lot of systems that were technologically speaking close to perfection and yet I can imagine that some got replaced by inferior systems, just because such staff is cheaper.
I think for OpenWrt to be useful in a business context the OpenWrt One could be kind of a big step, depending on whether a whole line will be created with increasingly better documentation.
Also, OpenWrt has already become more practical in a business setting, but the knowledge required to manage let's say 25 devices efficiently with cheap labor (so, someone who is not going to build their own kernels) is not exactly available abundantly.
I think the networking "language" used in OpenWrt is also outdated compared to what's available in a hyperscaler cloud environment and that's ultimately what senior engineers will compare it against and those will have the most meaningful voice in whether or not OpenWrt should be deployed somewhere.
I think, if you want a measure of how business friendly OpenWrt is, one need to be able to flash thirty devices per hour as a single individual without any knowledge of the device in question. So, no need to read a Wiki, no need to know about the vendor firmware or default passwords, nothing. So, the measure would be the number of devices flashable by let's say someone with a community college education that knows the difference between a router and a switch. That number should be displayed on the OpenWrt website and measured every year, until 30 is reached.
If, however the goal isn't broad adoption, then one shouldn't do that. Being clear about the goals in a project is also a good idea, because then the means to achieve those goals can be discussed. Also, without measuring how good you are doing, how do you know whether you are making progress?
This thread has now very much outlived its usefulness. The process for swapping the port functions is well understood, and the OP has expressed their dissatisfaction with the default condition.
The OP (and others that hold this opinion and/or need) has the options to:
- create their own custom builds with the ports swapped
- swap the port functions post-install
- bake-in a script to do the port swap at
firstboot(using the image builder/firmware-selector) - create a PR and convince the dev team that the ports should be swapped in the default state
- contribute to the wiki with the 'warning' and information about the process of how to swap the port functions.
Beyond all of that, this thread is no longer adding value and is now closed.