Just for future info, you won't be able to connect a client device directly to the LAN port on the RPi4 without going into the network config of that device and setting a VLAN tag of 10. And if you're planning to extend the wired network and add a switch in between your two current devices it'll need to be a managed switch.
Thanks, that's useful.
The LAN port on the RPi4 is only for the AP anyway in this setup, so that shouldn't be an issue, right?
And on the wired network, could I add an unmanaged switch to one of the AP's ethernet ports, create another br-lan.xx VLAN device, create something like lan-wired interfaces on both RPi and AP, and then join things up? Does that make sense? Clearly, if this works, it means it's a physical back door to the LAN, but let's assume I'm ok with that (i.e. I trust my guests).
If the answer is 'no, you need a managed switch', then fair enough - I was trying to avoid it as I have an unmanaged one already, but c'est la vie.
If you want to add additional wired access to just the LAN and are able to attach a switch to the AC2 then yeah a unmanaged one will be fine. You won't have to make any changes to any configs, just attach it to one of the 4 LAN ports (they're all set up as part of the lan vlan). You only need a managed switch if you were going to put it between the RPi4 and AC2.
1 Like
Understood. Again, thank you so much for your help @krazeh 
@krazeh I just wanted to let you know that I had some trouble once I cycled the power on the RPi and AC2. For whatever reason, I was no longer able to plug into a LAN port on the AC2 and get access to the RPi. Moreover, the RPi wouldn't get internet connectivity or, seemingly, receive any traffic routed from the AC2.
I tried reformatting the RPi SD card a few times and importing the backed up config (which included all the changes you mentioned above), but each time I did, I'd go from having access to the RPi to no having access. I then tried to make changes gradually, manually, by changing the config files over SSH, and again, I would lose access each time.
Eventually, I recreated your config through LuCI and did a diff on the new config files vs. the ones I'd backed up before. The only difference was not deleting this stanza:
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
... i.e. that stanza still exists, while all of the VLAN ones do too. This seems to have worked - I get internet connectivity and each WiFi network/SSID is getting (or not) appropriate access to VLANs on the RPi.
For what it's worth, the reason I thought about leaving this in was based on the OpenWRT DSA mini tutorial, which seems to leave it in.
I have no idea why this worked in the end, but it did, so hopefully that's the end of it! But thought you'd like to know, and perhaps you know what's going on
Cheers!
Oops, that's my bad. After deleting that stanza (which isn't necessary as you're not bridging any ports together) I should've said to use eth0 in place of br-lan for the option device lines.
1 Like
No worries. I guess that means that, in its current state, there's an additional, unnecessary state (i.e. I'm essentially creating an alias for eth0, in the form of br-lan)? That being the case, I'll probably leave it
You might want to edit your first answer, though, since it's marked as the solution? I'm not sure what etiquette is usually like on this forum, but might be worth it.
Thanks again!
Exactly. It's necessary on a device which multiple ports that you want to bridge together and treat as a single interface (such as on the AC2), but it's unnecessary when you're only dealing with a single port.
Good idea, I've gone back and made the changes.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.