I will test and report back
Is it possible to have a interface unmanaged and still run a DHCP server on it?
If you're talking about an unmanaged interface in OpenWrt where you would then have OpenWrt provide DHCP services -- no, this is not possible. You need to assign it an address and turn on the DHCP server. If you do that, you also need to ensure the following:
- DHCP advertised gateway and DNS are set properly (if not set, the server will advertise the OpenWrt device as those addresses)
- DHCP (port 67-68) is accepted by the OpenWrt firewall for that network (you probably need to create a zone for the network, unless you want it to use the lan firewall zone)... the details of this depend on the level of access hosts on that network should have in terms of connecting to services on the OpenWrt device.
An unmanaged interface doesn't interact with the OpenWrt kernel, so it can't run any local services. In a dumb AP the client's DHCP request from wifi is bridged over to the Ethernet VLAN to be processed by a router elsewhere in the network.
Excellent, i didnt think it was possible as it would not know what scope to hand out anyway.
Thanks guys
Please report back on the status of your testing.
And, if your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
OK, I restored from a old config and made some changes. Everything seems to be smooth sailing right now.
Anything I can do to declutter and clean it up?
Thanks.
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdc8:1c14:f964::/48'
config device
option name 'br-vlan102'
option type 'bridge'
list ports 'eth0.102'
option ipv6 '0'
option bridge_empty '1'
config device
option type 'bridge'
option name 'br-vlan101'
list ports 'eth0.101'
option ipv6 '0'
option bridge_empty '1'
config device
option name 'eth0.101'
option mtu '1500'
option ipv6 '0'
config device
option name 'wlan0'
option ipv6 '0'
config device
option name 'eth0'
option mtu '1500'
option ipv6 '0'
config device
option name 'eth0.102'
option mtu '1500'
option ipv6 '0'
config device
option name 'wlan0-1'
option ipv6 '0'
config device
option name 'wlan1'
option ipv6 '0'
config device
option type 'bridge'
option name 'br-vlan103'
list ports 'eth0.103'
option ipv6 '0'
option mtu '1500'
option macaddr '74:AC:B9:C4:38:CF'
option bridge_empty '1'
config device
option name 'eth0.103'
option mtu '1500'
option macaddr '74:AC:B9:C4:38:CF'
option ipv6 '0'
config interface 'vlan102'
option device 'br-vlan102'
option proto 'none'
config interface 'vlan103'
option proto 'static'
option device 'br-vlan103'
option ipaddr '172.16.103.1'
option netmask '255.255.255.240'
config interface 'vlan101'
option device 'br-vlan101'
option proto 'none'
config device
option name 'wlan0-2'
option ipv6 '0'
config device
option name 'wlan1-1'
option ipv6 '0'
- network 1/88 1%
Why did you restore from the previous configuration??!??!??
The files that we had worked on above were exactly as they should have been.
I knew my previous config was 100% working the way I wanted.
It was just the management vlan that was not working
To be clear, the files in comment 38 were perfect except for the management network association with a firewall zone (which I commented about in comment 39).
The config you have reloaded is messy and has mistakes/issues. It is not worth going through the hassle of trying to fix it, though, since we just spent the last 30 some posts doing exactly that (and we arrived at comment 38 where the files were correct).
If there is an issue with the management network, let's fix it from the state we were in in comment 38.
What exactly is messy with the config?
Apart from the management VLAN not requiring a bridge?
I had commented about that in multiple responses maybe 35 posts ago.
What was wrong with the management VLAN? You never mentioned there was an issue and then you went and restored an old file.
I'm honestly at a loss here. The files in comment 38 are what you should be using... and I can't understand why you would revert after all the work we put into this. If there is a problem, you should fix it from the state of comment 38.
Can we not just remove whats not needed?
sure...
remove all of this:
and then replace it with this:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd74:fac0:9b2c::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option type '8021q'
option ifname 'eth0'
option vid '101'
option name 'eth0.101'
option ipv6 '0'
config device
option type '8021q'
option ifname 'eth0'
option vid '102'
option name 'eth0.102'
option ipv6 '0'
config device
option type '8021q'
option ifname 'eth0'
option vid '103'
option name 'eth0.103'
option ipv6 '0'
config device
option type 'bridge'
option name 'br-vlan101'
list ports 'eth0.101'
option ipv6 '0'
config device
option type 'bridge'
option name 'br-vlan102'
list ports 'eth0.102'
option ipv6 '0'
config interface 'vlan103'
option device 'eth0.103'
option proto 'static'
option ipaddr '172.16.103.1'
option netmask '255.255.255.240'
config device
option name 'eth0'
config interface 'vlan101'
option proto 'none'
option device 'br-vlan101'
config interface 'vlan102'
option proto 'none'
option device 'br-vlan102'
Thank you for your help.
Cisco and OpenWrt may use 802.1Q VLAN's only.
On Cisco switch:
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk