[VOTE] OpenWrt Two

[Daniel Golle]

On Thu, Oct 09, 2025 at 07:40:31PM +0100, David Woodhouse wrote:
> On Mon, 2025-02-17 at 22:58 +0900, Sungbo Eo wrote:
> > On 2025-02-13 03:44, John Crispin wrote:
> > > Hi,
> > > 
> > > starting a [VOTE] to get approval allowing me to begin the development
> > > of OpenWrt "Two".
> > > 
> > > "Two" will have all of the features that "One" has with the following
> > > upgrades.
> > > 
> > > * MT7988
> > > * 10G SFP
> > > * 5G copper
> > > * 4 port 2.5G copper
> > > * 1-2 port 1G copper
> > > * Tri-band Wi-Fi 7
> > > 
> > > "Two" will be produced by GL.iNet and we are exploring options for US/EU
> > > based distribution.
> > > 
> > > "Two" will (hopefully) be in the 250$ region with yet again a portion of
> > > that being donated to the project.
> > > 
> > > expected availability is late '25.
> 
> And still PoE? On which port?
> 
> I'm just starting to play with the OpenWrt One that's been sitting on
> my desk for a while. I'm trying to understand why anyone would get PoE
> on the *WAN* port, if that's coming for their ISP's fibre/VDSL dongle.
> Seems like that port is always just going to be a single wire to
> whatever the uplink is.

The One got 1x 1GE and 1x 2.5GE, the assignment which of them is LAN
and WAN is pretty arbitary and can be changed according to your needs.
The decission to make 2.5GE port the PoE input was to make the One
suitable as an access point supplied by a 2.5GE PoE switch -- we wanted
the faster port to be with PoE.

> 
> Seems to me like I'd always want PoE to come from the internal network
> on the *LAN* side, surely? 
> 
> Which is fine on the One, as I can just use the 2.5G/PoE port as the
> internal one, connect the VDSL dongle to the 1G port, and wonder why
> the box and default configuration have them mislabelled.

On my case there aren't any labels destinguishing either port as WAN
or LAN. It's all just default configuration.

> 
> But on the Two, it's going to matter more. I'd really want the PoE to
> be on one of the four 2.5G ports attached to the switch, and *not* the
> single port. Otherwise there's going to be a lot more software bridging
> than necessary...

Thanks to 'bridger'[1] it is easy to avoid CPU-intense "software bridging"
from happening on MediaTek platforms which comes with MediaTek's PPE
offloading engine.

[1]: https://github.com/nbd168/bridger