Linksys MX4300 networking: DSA or SWCONFIG (or neither)?

Hi. I have a Linksys MX4300. How do I know if this platform is DSA or SWCONFIG?

ubus call system board
{
        "kernel": "6.6.86",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "Linksys MX4300",
        "board_name": "linksys,mx4300",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.1",
                "revision": "r28597-0425664679",
                "target": "qualcommax/ipq807x",
                "description": "OpenWrt 24.10.1 r28597-0425664679",
                "builddate": "1744562312"
        }
}
  • In the default /etc/config/network, there is no "config switch" section, so that implies not swconfig.
  • Using steps in How to detect DSA?, there are no hits for DEVTYPE=dsa
  • In Turris Omnia, Openwrt 18.06.2, VLANs, I did find opkg install kmod-ikconfig, after which /proc/config.gz reports CONFIG_NET_DSA=y

Given the results of /proc/config.gz, I guess it is safe to say the Linksys MX4300 is DSA? Is there another authoritative way (maybe less-dependent on a special package being installed) to query the system for whether it is DSA or swconfig or something else?

Thank you

The MX4300 is indeed DSA.

However, to generalize...

From a practical perspective, the easiest way to determine if a multi-port device is DSA would be to look at the default /etc/config/network file and find the br-lan device definition. A DSA device that looks something like this (there are variations to the theme, but this is the general structure):

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

By contrast, swconfig will look something like this:

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0.1'

...

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0t'
2 Likes

The MX4300 is indeed DSA.

It looks more like no switch at all (like on x86).

  • The toh says IPQ807x has no DSA support
  • This comment (old, 2022) says the driver is faking independent network cards.
  • The MX4300 Luci UI reports them as "Ethernet adapters" rather than "switch ports"

I agree the MX4300 is definitely not swconfig (no switch configuration in /etc/config/network).

The reason this matters to me is because I am trying to correctly configure VLANs and trunk ports and the system being DSA/swconfig/no-switch affects the ports and names used to configure bridge devices and such.

Do you have the device in hand? If so, what is the default state of the /etc/config/network file?

After a firstboot -y and a reboot:

root@OpenWrt:~# cat /etc/config/network                                                                                                                          
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 'xxxx:xxx:xxxx::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'

config device
        option name 'lan1'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config device
        option name 'lan2'
        option macaddr 'xx:xx:xx:xx:xx:xx'

config device
        option name 'lan3'
        option macaddr 'xx:xx:xx:xx:xx:xx'

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 interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'

Just a quick glance, and you may be right that the device doesn't use an actual switch chip. However, the structure of br-lan is setup by default with DSA syntax, so the kernel is presumably abstracting the hardware in the same way it does a switch.

That said, I don't think that it should matter... DSA/bridge-VLAN syntax should work for the VLANs.

I'd setup just one additional network so you have a total of 2 VLANs and verify that it is functioning as expected. If it doesn't work, post the configs (network, firewall, dhcp) here and we can review to ensure that there aren't any syntax or other config issues. And if there's no obvious cause, we can try another technique.

ipq807x/ ipq60xx/ ipq50xx do use a switch (apart from potential 1-2 >1 GBit/s ethernet ports), but currently neither swconfig nor DSA, but very rudimentary switchdev drivers (which make it look a bit like individual ports or DSA, it's still a switch though).

Thank you. I decided to configure like separate adapters, just because Luci is reporting them that way. Things are working for me.

One surprising thing I discovered: the "wan" adapter seems to have a stable MAC address (which I use for static DHCP), but the "lan" adapters seem to have unpredictable MAC addresses that are set at boot or something.

The firstboot configuration "hard-codes" their MAC addresses using option macaddr, but lacking that, they have unpredictable MAC addresses.

I discovered this because I had been adding the "lan" ports to the bridge device first, resulting in static DHCP not behaving as expected. Changing the configuration to add the "wan" adapter first solved that problem.

Are you configuring each port to carry just a single network, untagged -- basically treating them as individually routed ports? Or are you setting up trunk ports with 802.1q VLAN tags?

I have one trunk port and 3 access ports.

The Linksys MX4300 has 4 labeled ports on the device: "LAN1", "LAN2", and "LAN3", and "WAN". I have it configured as a dumb AP:

  • LAN1: trunk port (VLANs 1,3,4,5)
  • LAN2, WAN: "home" network access ports - "lan" interface on "br-lan" bridge (VLAN 1)
  • LAN3: "iot" network access port - "lan2" interface on "br-lan2" bridge (VLAN 4)

The "lan1" (VLAN 3) and "lan3" (VLAN 5) interfaces are for other WiFi networks.

This is my /etc/config/network where things are working (trunk port, wired IOT device, and WiFi networks):

config globals 'globals'
        option ula_prefix 'fd95:d45:b69d::/48'

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

config interface 'lan'
        option device 'br-lan'
        option proto 'dhcp'

config interface 'lan1'
        option device 'br-lan1'
        option proto 'none'

config interface 'lan2'
        option device 'br-lan2'
        option proto 'none'

config interface 'lan3'
        option device 'br-lan3'
        option proto 'none'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'wan'
        list ports 'lan1'
        list ports 'lan2'

config device
        option name 'br-lan1'
        option type 'bridge'
        list ports 'lan1.3'

config device
        option name 'br-lan2'
        option type 'bridge'
        list ports 'lan3'
        list ports 'lan1.4'

config device
        option name 'br-lan3'
        option type 'bridge'
        list ports 'lan1.5'

The above "style" of configuration seems to work for this MX4300 device (no configuration for switch or VLAN filtering). It is not working for my DSA device; I think I have to set up some form of VLAN filtering configuration on the bridge devices.

Yes, this would be wrong for DSA proper.

Would you be willing to try a different method on the MX4300? I think I can come up with the right recipe that should work on both this device and a real DSA system.

Sure, I don't mind.

Ok.... let's give it a shot. Make a backup and then reset to defaults.

Next...
Delete the wan network interfaces:

add the wan port to br-lan:

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'wan'

add bridge VLANs:

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'lan1:u*'
        list ports 'lan2:u*'
        list ports 'wan:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '3'
        list ports 'lan1:t'

config bridge-vlan
        option device 'br-lan'
        option vlan '4'
        list ports 'lan1:t'
        list ports 'lan3:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '5'
        list ports 'lan1:t'

Now, edit your lan interface to use br-lan.1 and DHCP:

config interface 'lan'
        option device 'br-lan.1'
        option proto 'dhcp'

And finally create your other network interfaces (unmanaged) using br-lan.x:

config interface 'vlan3'
        option device 'br-lan.3'
        option proto 'none'

config interface 'vlan4'
        option device 'br-lan.4'
        option proto 'none'

config interface 'vlan5'
        option device 'br-lan.5'
        option proto 'none'

At this point, you can now create the SSIDs and connect them to the respective networks.

Restart and test.

Hey, thanks! This is just a regular "DSA-style" config, correct? (Place all ports under a single bridge device, set up VLANs inside the bridge, then configure interfaces to point at the bridge VLANs.)

I suppose it could be nice to have a single config that works on both types of systems, but I'd rather have a "minimal" configuration, even that means multiple such configurations for different types of systems.

precisely.

Yes. I'd recommend using this same method (bridge-vlans) for both devices. It's obviously required for true DSA, but it is good to use the same on both since it actually simplifies your config from a human/cognitive aspect. And another consideration is that the non-bridge-vlan approach absolutely won't work with a DSA device, so by keeping your configs the same will reduce the risk that you might try to use the incompatible approach on the DSA device.

Honestly, I would argue that the DSA + bridge-vlan method is no more complex than your non-bridge-vlan approach.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.