Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3283 - LUCI unavailable when WAN MAC specified #8154

Open
openwrt-bot opened this issue Aug 14, 2020 · 1 comment
Open

FS#3283 - LUCI unavailable when WAN MAC specified #8154

openwrt-bot opened this issue Aug 14, 2020 · 1 comment
Labels

Comments

@openwrt-bot
Copy link

rldleblanc:

Running 'OpenWrt 19.07.3 r11063-85e04e9f46' on a Linksys WRT32ACM v1 if you set the WAN MAC to something other than what it really is, you can not access LUCI using the internal router IP (192.168.1.1) when the WAN is plugged in. If unplug the WAN, access to 192.168.1.1 is restored. This does not impact the IPv6 access via openwrt.lan. Repeatedly plugging and unplugging the WAN makes the problem appear and go away. I tried all kinds of Firewall rules and port forwards, rebooted and reset many times. I reverted the WAN MAC back to the actual hardware address and it works just fine. It appears that eth1.2 gets the new MAC, but the underlying eth1 still has the burned in MAC and I think that the card drops the packets (VLAN interfaces should have the same MAC as the parent). I'm now noticing that the MAC lines up with the wlan0 interface that was down and that could also contribute to the problem.

Supply the following if possible:

  • Device problem occurs on
  • Software versions of OpenWrt/LEDE release, packages, etc.
  • Steps to reproduce

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
link/ether 24:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff
inet6 fe80::26f5:a2ff:fe2f:39d8/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
link/ether 26:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff
inet6 fe80::24f5:a2ff:fe2f:39d8/64 scope link
valid_lft forever preferred_lft forever
5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 24:f5:a2:2f:39:da brd ff:ff:ff:ff:ff:ff
6: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 24:f5:a2:2f:39:d9 brd ff:ff:ff:ff:ff:ff
7: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 24:f5:a2:2f:39:db brd ff:ff:ff:ff:ff:ff
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 26:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 2600:6c52:6300:74d6::1/64 scope global dynamic
valid_lft 600870sec preferred_lft 600870sec
inet6 fdaa:bf91:a905::1/60 scope global
valid_lft forever preferred_lft forever
inet6 fe80::24f5:a2ff:fe2f:39d8/64 scope link
valid_lft forever preferred_lft forever
9: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
link/ether 26:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff
11: eth1.2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 24:f5:a2:2f:39:da brd ff:ff:ff:ff:ff:ff
inet xx.xx.xx.xx/24 brd 24.176.239.255 scope global eth1.2
valid_lft forever preferred_lft forever
inet6 2600:6c52:7008:400:d99f:4eea:b0fd:a61/128 scope global dynamic
valid_lft 600870sec preferred_lft 600870sec
inet6 fe80::26f5:a2ff:fe2f:39da/64 scope link
valid_lft forever preferred_lft forever

@openwrt-bot
Copy link
Author

rldleblanc:

It appears that setting the MAC to not match the wlan interfaces works even though the MAC does not match the parent adapter. I guess it's up to you if you want to make them match or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant