OK, another "interesting" observation ...
- Using my iOS device as a client => DHCP fails
- Using a Windows machine as a client => DHCP succeeds
OK, another "interesting" observation ...
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:
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
#!/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?
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!
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 . 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
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 . 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?
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.
Gotcha - thanks for the info! Will wait on DSA updates, see if that resolves my issue. Appreciate it.
Still no LuCI (minor), but wlan seems to get through the switch now (latest build, netifd updates) ... others seeing this as well?
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