I have a rule about not flashing routers that work, and last month I broke it, bricked the thing, and spent an evening with a serial cable bringing it back. You'd think that would have settled me. It did not. Because there's a different router in the cupboard, a cheap eight-port thing I use to carve the home network into a few VLANs, and the stock firmware's idea of VLAN tagging is a web form that lies to you. You set a tag, you save, you reload the page, and the tag has quietly reverted to something else. I wanted the actual control that OpenWrt gives you over the switch, and I convinced myself that this time it was justified.
It mostly wasn't. But I learned a few things, and unlike last time I did it without ending up at the soldering iron at midnight.
doing it with a net this time
The single best decision I made was reading the wiki page for the exact hardware revision before touching anything. Routers lie about what they are. The box says one model, the sticker says a revision, and the flash layout and switch chip can differ enough between revisions that the wrong image bricks you in the way I'd bricked the last one. So step one was confirming the revision from the bootloader output, not the sticker.
picocom -b 115200 /dev/ttyUSB0
I had the serial console attached before I started, not after I'd broken something. Three pads near the SoC, ground confirmed against the shielding with a multimeter, TX and RX on a 3.3V USB-to-TTL adapter, voltage line left disconnected because the board powers itself and you'll only fight it otherwise. The point of having the console up front is that you can watch the flash happen and read the errors as they occur, rather than guessing at a blinking LED afterwards.
the flash, and the part the web UI hides
The factory image went on through the stock firmware's own upgrade page, which is the supported path for the first flash. It came up on OpenWrt, I got a LuCI login, and so far this was identical to every flash that's ever gone well right before it doesn't.
The VLAN work was the bit I'd actually come for. On this hardware the switch is a separate chip from the CPU, and OpenWrt exposes it through swconfig and the config switch_vlan blocks in /etc/config/network. The stock firmware had been hiding all of this behind a form, and the form was where the lying happened. Here it's explicit: a VLAN has an ID, a list of ports, and each port is either tagged or untagged, and you can see all of it.
config switch_vlan
option device 'switch0'
option vlan '20'
option ports '0t 3 4'
That 0t is the trunk port carrying tag 20, ports 3 and 4 are untagged access ports on that VLAN. The CPU port nearly always needs the t, and forgetting the t on the CPU port is the classic way to make a VLAN that works between two switch ports but never reaches the router itself, which is a wonderful way to lock yourself out. Having the serial console meant that when I did exactly that, locked myself out over the network, I could just fix the config from the console and reload, instead of reaching for the reset button and the recovery dance.
The mapping between the port numbers in the config and the physical sockets on the back of the box is its own small adventure, and it is almost never the obvious left-to-right order you'd hope for. On this unit port 0 was the CPU, ports 1 through 4 were the LAN sockets but in a reversed order, and the WAN socket was a number I'd never have guessed. The wiki had a table for it. I trusted the table over my eyes, confirmed each one by plugging a laptop into a single socket at a time and watching which switch port lit up in swconfig dev switch0 show, and only then committed the config. Half an hour of dull verification that saved me from an evening of "why is the guest VLAN coming out of the wrong hole".
did the tagging actually work
It did, eventually, and properly. The VLANs now stay where I put them. Traffic on the guest VLAN can't see the main network, the tag on the trunk is the tag I set and stays the tag I set across reboots, and I can verify it with tcpdump on the trunk port and watch the 802.1Q headers go by rather than trusting a web form's word for it. That's a genuine improvement over the stock firmware, which I could never actually confirm was doing what it claimed.
was it worth it
Here's the honest tally. I gained real, inspectable VLAN configuration, and I gained the ability to see what the switch chip is actually doing, both of which the stock firmware denied me. Against that, I spent an evening, I locked myself out once, and the network this router serves is my house, not a business, so the stakes were a few hours of my own annoyance.
The thing I'd tell anyone tempted to do the same: the feature you want is probably real and OpenWrt probably does it better, but check the hardware revision against the wiki before every flash, attach the serial console before you need it rather than after, and accept that you will lock yourself out of the network at least once over a VLAN tag you forgot to trunk. If those three things are fine with you, go ahead. If the router is in a cupboard doing its job and you have no console handy, leave it alone. I will, I'm sure, ignore my own advice again before the year is out.