Mtk7621 netifd can not receive switch link up/down events?

For Developers
1

I can get mt7621 switch driver netdev_info report the port link up or down info. But can not recv anything from netlink. So netifd will don't call scripts in /lib/hotplug.d/iface.

image

2

Yes this is correct. Switch driver port level link events are not propagated to the higher layers. Even if they were, what would be the logic for invoking up/down? When all ports of a VLAN minus the CPU port are down? What if the port is part of multiple VLANs? What if there's multiple CPU ports? Etc.

3

I am using switch port 4 act as wan. And wan use dhcp proto . When link down/up, eth0.2 will never renew ip. How can deal with this case.

4

You can't, apart from modifying the drivers to somehow emit an uevent you can catch from userspace.

5

I checked in ar9531. when switch port down, netifd will recv eth0, eth0.1. Is there any driver i can refer to?

6

Yeah, but the switch port is always up. You need to handle the case when an external port goes down. The only way I see is to broadcast the port events you see in dmesg as uevent where you can then pick them up with netifd or /etc/hotplug.d/.

7

Thank you. I'll try it.

8

Another solution is to backport DSA driver for MT7530, which has got MT7621 support.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/dsa
With DSA driver, all of the switch ports are treated as separate network devices

9

I don't like this solutions.

10

for now I use a scripts to watch the port status and trigger an ifconfig down/up when it change

see: https://github.com/x-wrt/x-wrt/commit/6393e14202d4946a0a54134dafa720c2969a4364

for example: sample config

eth0.2 -- switch port 4 -- vlan 2  -- wan

eth0.1 -- switch port 0 1 2 3 -- vlan 1 -- lan (lan1 lan2 lan3 lan3)

for wan:
if switch port4 link status change, it trigger

for lan:
if switch port1 link status change and port0,2,3 no change, it also trigger

1 Like
11

I'm digging up this old post because this issue is still relevant.

I have some projects where I use ar9331 SoC-based devices. These all have two real ethernet interfaces. A good example of this is the GL.iNet GL-AR150. The WAN port is eth0 and the LAN port is eth1.

Now recently I've been working with the GL.iNet GL-MT300N-V2. Same exact plastic chassis and two network jacks, but it only has one real network interface. The WAN port is eth0.1 and the LAN port is eth0.2. Link state events don't happen because the eth0.1 and eth0.2 layer-3 interfaces never go down.

I can manually check the switchport states with "swconfig dev switch0 port 1 get link" and the kernel generates some noise with a "rt3050-esw 10110000.esw: link changed 0x02" message, but I want some kind of event so that I don't have to write a stupid daemon that constantly polls the switch port status.

Unfortunately it looks like OpenWRT has no support for switch events. Given the very large numbers of modern devices which mandate the use of switchports, I think this is a mistake.

This makes some dual-uplink/redundancy configurations impossible because we don't get link state. Routing protocols which use link states are broken.

All-in-all this just makes the user/administrator's life more difficult with no up-side. I suggest that OpenWRT needs a solution for this. What would Cisco/Juniper do if they forced all their ISR ethernet interfaces to sit behind a switch?

I don't think this is OpenWRT's fault. Hardware vendors should not be designing routers where the WAN ports are behind a single-port switch. Then again, it gives us owners some flexibility too. We just need to accommodate this design change, and that means being able to control the link-state of layer-3 devices based on layer-2 link status.

12

Another problem, as ycsunjane above noted, is that network interfaces using a DHCP client behind an internal switch won't get a hup signal, resulting in a delay for obtaining a DHCP lease. This could take up to 9 minutes depending on the state of the DHCP client backoff timer.

I was just tinkering around with such an interface and was noting that the DHCP client was taking a long time to get a lease. It took something like six minutes for that interface to come up.