I'm running a Netgear R7800 (Hnyman 22.03) configured as a dumb Access Point using this guide (https://openwrt.org/docs/guide-user/network/wifi/dumbap). WiFi access works fine for my devices, but when I plug a device (Armbian Linux server) in to the Ethernet port the server doesn't connect. I tried it before setting up VLANs and I tried it on a VLAN. WiFi devices on these VLANs work fine. The device works fine if it's directly plugged into the router. The device used to work fine on the same router with stock firmware.
Does anyone know why this device may be refusing to connect to the Access Point?
AP Switch Panel is below. Device is plugged into Eth4, but does not connect despite multiple attempts to reconnect (e.g., different Ethernet cables, manual configuration on the device, alternative configuration on the device (i.e., sudo ethtool -s eth0 speed 100 duplex full autoneg off))
Mixing tagged- and untagged traffic on the same ports (LAN1) generally isn't the best approach, as some devices can't cope with that (the r7800 can, but your clients may not, so at least try it without).
If I make VLAN 1 tagged on LAN1 (so all VLANs are tagged on LAN1), I am unable to access the web page of the access point, but WiFi on the AP still works and I can still access the router with WiFi devices. Do you know why I am no longer able to access the AP web terminal when I make VLAN1 tagged on LAN1?
Is the goal to the armbian Linux server available on vlan10? If so, set lan4 to untagged on vlan10 and all other lan4 to "off".
You said that you followed the dumb ap guide? Did you disable the dnsmasq it said to in the guide? If so, that is why you aren't getting an ip address when you plug into lan4.
If you share the idea of a trunk only port with only tagged yes, but the issue here maybe that 'tagged' vlan1 which is already the most common and default vlan for simple devices might cause more issues on a lot of client devices compared to vlan1 untagged + combined with tagged others on that same port.
I assume you're building a multiple-network dumb AP. That isn't in the guide, though it could be. In this use case, several networks are trunked back to a main router with VLANs on an Ethernet cable. The main router does all routing, DHCP, DNS, etc-- the AP remains "dumb" in that it functions as a layer 2 wireless to wired converter, but now for more than one network.
So first get the trunk cable working with VLAN 1 as tagged "administrative" network on the main router. Think of Ethernet connections as two modes, either "trunks" where everything is tagged, or "access" where only one network is attached, and it is untagged. Those are for use with PCs, servers, etc. that are not VLAN-aware.
Each of the user networks need a bridge and a dummy network (protocol: Unmanaged in the GUI, or proto none on the CLI). The bridges should be named br-guest etc and have eth1.X (X being the VLAN number for that network) as its only member. Make sure that eth1 without a VLAN number does not appear in your configuration-- it needs to be tagged on all networks it is used for.
The dummy networks are named guest etc (without br-) and have the corresponding bridge as its physical device. Dummy networks don't have any layer 3 functionality but they have to be present or the configure scripts won't actually instantiate the bridges. Then in the wifi config of each AP, set Network to guest, etc. depending on the purpose of the AP.
Since you're not routing to a WAN, you can delete the WAN VLAN (2), and the wan and wan6 networks. The WAN Ethernet port on the back of the router is equal in the switch, it can be assigned to any network(s) just like the other four.
The intent was to have the Linux server on vlan1, but I was trying it on other VLANs in case that happened to fix it.
LAN1 is the connection back to the router (an OPNsense router). I'm new to OPNsense and OpenWrt, but I don't think there is any specific configuration needed for OPNsense to have tagged vs untagged traffic on a specific interface. I disabled dnsmasq as it said in the guide, but I thought that would be the right approach since both DNS and DHCP is performed on the router.
The intended setup was a relatively simple setup with 1 router (OPNsense) and 1 AP and VLANs. However, I've been having performance issues that I think are related to incorrect configuration on my end. For example, I've been having this issue on the LAN port, dropped WiFi connections (particularly on the 5 GHz WiFi), and occasional unresponsive internet. I think my ambition was a bit too big for my current skill-set and so I "gave up". I reset the OpenWrt unit and set it up as a standard router with VLANs. So far, it's working without any of these previous issues (but the dropped 5 GHz WiFi took a day or so to show up so I'll wait and see). If it's any help to future people, after I set up the OpenWrt box as a router, I was able to set it up by repeatedly unplugging and repulgging the Linux server, then reconfiguring the Linux server Ethernet using ethtool (e.g., sudo ethtool -s eth0 speed 100 duplex full autoneg off, sudo ethtool -s eth0 autoneg on).
Thank you all for your help and advice! It's disappointing I wasn't able to get the original setup to work, but the current OpenWrt setup works great. I'm new to OpenWrt, but so far I'm really impressed with the features available and community!
The point I was trying to make is that if a network is tagged on a port of one device, it must also be tagged on the port of the device on the other side of the cable. The fact that VLAN1 is often used as the default untagged network is not directly relevant -- what matters is that the tag status matches on each side of a link.
There is certainly a specific configuration required to set tagged vs untagged on any OS/device that supports VLANs. In the case of a routed port (not switched) on OpenWrt, the method is simply specifying ethx.y (where y is the VLAN ID and it will be tagged). With a switch port, the method depends on if your device uses swconfig or DSA, but the point is that there is always a way to configure tagged vs untagged. And this will be true for OpenSense, too.
