@stangri you did this for the Sophos devices in Looking for users with specific Sophos x86-based routers!.
Could we do the same for CloudGenix ion 2000 ?
root@OpenWrt:~# for file in sys_vendor board_vendor product_name board_name prod
uct_version; do
> cat /sys/devices/virtual/dmi/id/$file
> done
CloudGenix
To be filled by O.E.M.
ion 2000
To be filled by O.E.M.
2.1
root@OpenWrt:~# find /sys/devices -type d -name eth0
/sys/devices/pci0000:00/0000:00:14.0/net/eth0
root@OpenWrt:~# find /sys/devices -type d -name eth1
/sys/devices/pci0000:00/0000:00:14.1/net/eth1
root@OpenWrt:~# find /sys/devices -type d -name eth2
/sys/devices/pci0000:00/0000:00:14.2/net/eth2
root@OpenWrt:~# find /sys/devices -type d -name eth3
/sys/devices/pci0000:00/0000:00:14.3/net/eth3
root@OpenWrt:~# find /sys/devices -type d -name eth4
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/net/eth4
root@OpenWrt:~# find /sys/devices -type d -name eth5
/sys/devices/pci0000:00/0000:00:02.0/0000:02:00.0/net/eth5
root@OpenWrt:~# ubus call system board
{
"kernel": "6.6.93",
"hostname": "OpenWrt",
"system": "Intel(R) Atom(TM) CPU C2558 @ 2.40GHz",
"model": "CloudGenix ion 2000",
"board_name": "cloudgenix-ion-2000",
"rootfs_type": "ext4",
"release": {
"distribution": "OpenWrt",
"version": "24.10.2",
"revision": "r28739-d9340319c6",
"target": "x86/64",
"description": "OpenWrt 24.10.2 r28739-d9340319c6",
"builddate": "1750711236"
}
}
I was not successful at first and didn't have time to revisit the PR.
I believe the renamed ixgbe devices were not coming up on boot, while the igb were. I've asked previous committers, but never properly sought help.
I see.
Then let me know if you want to follow up.
I'll post the board.json file here, for those who want to add the ports by hand.
root@OpenWrt:~# cat /etc/board.json
{
"model": {
"id": "cloudgenix-ion-2000",
"name": "CloudGenix ion 2000"
},
"network": {
"lan": {
"ports": [
"eth0",
"eth2",
"eth3",
"eth4",
"eth5"
],
"protocol": "static"
},
"wan": {
"device": "eth1",
"protocol": "dhcp"
}
}
}
1 Like
I'm not sure if every single ion 2000 unit is the same, but the changes below worked for me to set the "Controller" port to wan and align the numbers on the box to eth<x> in openwrt.
/etc/board.d/02_network - add the following after the last existing condition (right before the esac line)
cloudgenix-ion-2000)
ucidef_set_network_device_path "eth2" "pci0000:00/0000:00:14.0"
ucidef_set_network_device_path "eth3" "pci0000:00/0000:00:14.1"
ucidef_set_network_device_path "eth4" "pci0000:00/0000:00:14.2"
ucidef_set_network_device_path "eth5" "pci0000:00/0000:00:14.3"
ucidef_set_network_device_path "eth0" "pci0000:00/0000:00:01.0/0000:01:00.0"
ucidef_set_network_device_path "eth1" "pci0000:00/0000:00:02.0/0000:02:00.0"
ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5" "eth0"
;;
/etc/boards.json
{
"model": {
"id": "cloudgenix-ion-2000",
"name": "CloudGenix ion 2000"
},
"network": {
"lan": {
"ports": [
"eth1",
"eth2",
"eth3",
"eth4",
"eth5"
],
"protocol": "static"
},
"wan": {
"device": "eth0",
"protocol": "dhcp"
}
}
}
I added these two paths to /etc/sysupgrade.conf and reimaged. It required an extra reboot, but the configuration survived the upgrade.
1 Like
Adding @frollic
The port remaps don’t seem to be working for me even after several reboots. I am using the squashfs rather than the ext4 install image though
Specifically, the physical-to-logical mapping I see is the same as the default:
Controller eth4
Port 1 eth5
Port 2 eth0
Port 3 eth1
Port 4 eth2
Port 5 eth3
I don't own the hw any more, but I would check if the PCI paths match your hw.
Are you on 24.10 ?
24.10 and I confirmed the paths match before applying the changes to the files
Then I'm out of ideas, except perhaps the board_name is different in your case.
It's not the end of the world though, just assign the ports to the firewall zones by hand.
Thanks for the workaround
An interesting thing about the original instructions is that it did activate the i210 ports
Also interesting, OPNsense enumerates the ports correctly in left-to-right order
Linux and FreeBSD have a different order of network device detection.
ION 2000 has two blocks of network controllers, a block of two Intel i210 and a block of four Intel i354. On Linux (including OpenWrt), the 4xi354 block is detected first; on FreeBSD (including OPNsense), the 2xi210 block is detected first.
It gets even funnier on devices with expansion modules. On Linux, onboard network controllers are detected first; on FreeBSD, network controllers on expansion modules are detected first.
This is difficult only first 12 times you encounter it. 
Eventually, you just accept that some devices are weird that way. So you do three things, (1) cat /etc/config/network (to see which port is designated LAN and which is WAN; usually, it’s eth0 and eth1 respectively), (2) sticking a live Ethernet cable into every network port in turn and watching the console react (until you find the LAN and WAN ports), and (3) edit /etc/config/network to reflect your preferences (if they differ from the default).
Thanks for the explanation.
I already know the paths for each of the ports and their default names in OpenWRT. What could I do to /etc/config/network, if anything, that would map the ports from left to right as eth0 to eth5?
Not that easy in Openwrt, since the OS could detect the NICs in a different order on every boot.
There are scripts posted at the forum, which will get you the fixed port order by "moving" them around if needed.
Wow! Are there underlying race conditions in OpenWRT that cause this to happen?
I have a few mini-PCs with multiple NIC controllers running other Linux distros (PVE, PBS, Xpenology) that don’t seem to be doing this.
Yeah, AFAIK OpenWRT doesn't keep track of MACs, same port can get diff name on every boot.