LuCI Missing Switch (DSA)

OK, another "interesting" observation ...

  1. Using my iOS device as a client => DHCP fails
  2. Using a Windows machine as a client => DHCP succeeds

Huh?!?!

my windows clients (all clients) fail to make it tto WAn from WLAN. are you sure you are not getting cached requests in windows?

Just tried to make an AP with a mamba using UCI config in /etc/config/network and what seemed like a reasonable config did not go out the door. But adding a hotplug to set things up under /etc/hotplug.d/iface did allow wireless to setup and work.

I think I may be - agreed!

I see the files there, but still not working. What exactly did you modify? Thanks!

I spent ~10 ninutes on this, modified a OOTB /etc/config/network which did not work on first try, so modified a /etc/hotplug.d//iface/21-lan file I had sitting around. I suspect that just adding things to vlan 1 would get the job done, but did not try any other possibilities. regardless this is what I had when it worked:

network
config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd34:e394:1ca0::/48'

config interface 'lan'
	option type 'bridge'
	option force_link '1'
	option ifname 'lan1 lan2 lan3 lan4 wan'
	option proto 'dhcp'
	option ip6assign '60'

config device 'lan_lan1_dev'
	option name 'lan1'
	option macaddr '11:22:33:44:55:66'

config device 'lan_lan2_dev'
	option name 'lan2'
	option macaddr '11:22:33:44:55:66'

config device 'lan_lan3_dev'
	option name 'lan3'
	option macaddr '11:22:33:44:55:66'

config device 'lan_lan4_dev'
	option name 'lan4'
	option macaddr '11:22:33:44:55:66'

config device 'wan_wan_dev'
	option name 'wan'
	option macaddr '11:22:33:44:55:66'

config interface 'lan6'
	option proto 'dhcpv6'
	option ifname '@lan'
	option reqprefix no

21-lan
#!/bin/sh
[ $INTERFACE = lan -a $ACTION = ifup ] || exit 0

#### enable VLAN filtering
ip link set dev br-lan type bridge vlan_filtering 1

#### clear out vlan 1
bridge v del dev lan1 vid 1
bridge v del dev lan2 vid 1
bridge v del dev lan3 vid 1
bridge v del dev lan4 vid 1
bridge v del dev wan vid 1
bridge v del dev wlan0 vid 1
bridge v del dev wlan1 vid 1
bridge v del dev br-lan self vid 1

#### set vlans lan1
bridge v add dev lan1 vid 10 pvid untagged

#### set vlans lan2
bridge v add dev lan2 vid 10 pvid untagged

#### set vlans lan3
bridge v add dev lan3 vid 10 pvid untagged

#### set vlans lan4
bridge v add dev lan4 vid 10 pvid untagged

#### set vlans wan
bridge v add dev wan vid 10 pvid untagged

#### set vlans wlan0
bridge v add dev wlan0 vid 10 pvid untagged

#### set vlans wlan1
bridge v add dev wlan1 vid 10 pvid untagged

#### set vlans cpu port
bridge v add dev br-lan self vid 10 pvid untagged

certainly not to be construed as only / best. PR2942 might offer some insight until the other method is available.

This makes sense, thanks! But I checked my vlan (default, I haven't messed with it) - using bridge (ip-bridge). Got the following,

> bridge vlan show
port              vlan-id
ethernet1         1 PVID Egress Untagged
ethernet2         1 PVID Egress Untagged
ethernet3         1 PVID Egress Untagged
ethernet4         1 PVID Egress Untagged
internet          1 PVID Egress Untagged
br-lan            1 PVID Egress Untagged
wlan0             1 PVID Egress Untagged
wlan1             1 PVID Egress Untagged

So seems like it should be OK, no?

Thanks!

Yes, that is what I saw, and it did not work (but I thought it should), so I just tried the 21-lan script. I have a feeling that maybe just leaving things that way, but creating a script as simple as

#!/bin/sh
[ $INTERFACE = lan -a $ACTION = ifup ] || exit 0

#### enable VLAN filtering
ip link set dev br-lan type bridge vlan_filtering 1

is probably worth a shot.

Actually, just tried your 21-lan script, restarted network (serivce). I know it took, because now,

port              vlan-id
ethernet1         10 PVID Egress Untagged
ethernet2         10 PVID Egress Untagged
ethernet3         10 PVID Egress Untagged
ethernet4         10 PVID Egress Untagged
internet          10 PVID Egress Untagged
br-lan            10 PVID Egress Untagged
wlan1             10 PVID Egress Untagged
wlan0             10 PVID Egress Untagged

Still no joy for wlan though. Pulling my hair out! :wink:

Thanks!

Man, it's really odd - some traffic gets through (if I manually force the IP address ... DHCP not working). tcpdump shows traffic, just not able yet to figure out the pattern to what is getting blocked :frowning_face:. With a fixed (forced) IP address, ping seems to get through.

Agreed! Also tried vlan_filtering 0 (i.e. off), no joy in either case :frowning_face:

Thanks!

When I tried this I had the patch cable connected from the WAN port to a switch, wondering if there is any difference between a NIC on the switch as opposed to the other one.

Sorry, you lost me there :frowning_face:. I am going to a switch in the uplink direction. I also tried making the uplink from the WAN, and also LAN (re-connected). No difference, wlan not getting through. But it is working for you now?

Thanks!

I was just curious if there might be a difference in the way the WAN port behaves compared to the NICs that are on the actual switch in the router, given the difference in the setup for DSA. I am not using the mamba as an AP, I just knocked it down to test as to the issue you were seeing.

1 Like

Gotcha - thanks for the info! Will wait on DSA updates, see if that resolves my issue. Appreciate it.

Hi,

Still no LuCI (minor), but wlan seems to get through the switch now (latest build, netifd updates) ... others seeing this as well?

Thanks!

Does anybody know the latest status on the DSA enabled LuCI stuff? I built latest master which seems still missing it. Any pointers are welcome.

You could try adding PR4307 to your build, no idea as of correctness.

the commit for luci web interface for DSA was merged and should be available in shapshot https://github.com/openwrt/luci/pull/4307#issuecomment-802100143

2 Likes