No problem. It was quite a fun and interesting challenge to put all the pieces together and stumble through PHP, Volt, etc to get the web GUI piece working.
AFAIK, there aren't any publicly available BIOS updates for the 610. I'd recommend against doing the BIOS updates for any of these, unless you need a feature like SR-IOV working (I vaguely recall nmpu saying that there was an issue with SR-IOV not working correctly on older firmwares). I tried flashing a VEP1400-X BIOS onto one of my 610s and while it did flash correctly, start-up speed was stalled because the BIOS in the first slot (the one I "upgraded") would always crash and then the backup slot would have to take over. I eventually managed to fix it in DiagOS by switching the BIOS slot to the second slot (there's a tool in DiagOS that does this, I'd have to check since it's been months), dumping the second slot, switching back to the first and using flashrom (not the DELL provided tool) to reflash the first slot.
The watchdog is taken care of in the vep1400-init early script; currently it is "hard-coded" to just turn it off and unless the timer was set really short, OPNsense usually boots fast enough to hit the early script and turn off the watchdog, so messing with buttons or installing/booting DiagOS isn't needed anymore if you're turning this into an OPNsense appliance (and using the plug-in/installer image).
Not at a hardware level like 620+ (VEP1400-X) units. You can however, approximate this by editing the vep1400-init script and adjusting the etherswitchcfg to have each port on a separate VLAN and creating the relevant VLANs in OPNsense. I had been planning on creating a separate plugin to manage the etherswitchcfg, but before I do that, I should really work on my PHP skills and my understanding of how the MVC (web GUI) framework in OPNsense works. My drive just hasn't been there though.
Anyway, the relevant lines in /usr/local/etc/rc.syshook.d/50-vep1400-init (lines 50-57):
Code:
if [ -e /dev/etherswitch0 ]; then
etherswitchcfg config vlan_mode dot1q
etherswitchcfg port1 pvid 2 port2 pvid 2 port3 pvid 2 port4 pvid 2 port5 pvid 2 port6 pvid 3 port9 pvid 3 port10 pvid 2 vlangroup0 vlan 2 members 1,2,3,4,5,10 vlangroup1 vlan 3 members 6,9
echo "Marvell 88E6190 configured. LAN ports are 1-5 and are connected to ix0. WAN is on port 6 and is connected to ix1."
logger -t "vep1400-hw" "Marvell 88E6190 configured. LAN is on ports 1-5 and is connected to ix0. WAN is on port 6 and is connected to ix1."
else
logger -t "vep1400-hw" "VEP1400 detected, but no etherswitch dev found. Is patched kernel installed?"
fi
Code:
if [ -e /dev/etherswitch0 ]; then
etherswitchcfg config vlan_mode dot1q
# set the PVIDs for each port first, can't start with PVID 1 on access ports cause that's the native VLAN for untagged traffic
etherswitchcfg port1 pvid 2 port2 pvid 3 port3 pvid 4 port4 pvid 5 port5 pvid 6 port6 pvid 7 port9 pvid 1 port10 pvid 1
# create VLAN groups on switch. Port 10 is CPU port 0 aka ix0, Port 9 is CPU port 1 aka ix1
# PVIDs above have to match VLAN defined in the groups below
# in this configuration, CPU ports have to be tagged on both the switch and in the OS
etherswitchcfg vlangroup0 vlan 2 members 1,10t
etherswitchcfg vlangroup1 vlan 3 members 2,10t
etherswitchcfg vlangroup2 vlan 4 members 3,10t
etherswitchcfg vlangroup3 vlan 5 members 4,9t
etherswitchcfg vlangroup4 vlan 6 members 5,9t
etherswitchcfg vlangroup5 vlan 7 members 6,9t
#echo "Marvell 88E6190 configured. LAN ports are 1-5 and are connected to ix0. WAN is on port 6 and is connected to ix1."
#logger -t "vep1400-hw" "Marvell 88E6190 configured. LAN is on ports 1-5 and is connected to ix0. WAN is on port 6 and is connected to ix1."
else
logger -t "vep1400-hw" "VEP1400 detected, but no etherswitch dev found. Is patched kernel installed?"
fiYes, you were able to upgrade without losing the switch because I "pinned" (borrowing a Linux bootloader term) the kernel so that it doesn't get overwritten during the upgrade. The downside to this is that you didn't really upgrade the kernel, it's still on 26.7.2. I need to build a new one with the 26.7.4 patches. I'll either edit this post or make a new one with the new kernel set when it's built.
It's fine (sort of) to run an older kernel with a newer userspace, as long as they are same version (in this case 15.1). FreeBSD expects userspace and the kernel to be more tightly bound version-wise (compared to Linux) because it's all one distro and it's all built at the same time, as far as I understand.
The normal locations for FreeBSD kernels are /boot/kernel/ and /boot/kernel.old/. When a kernel update is done, the system moves the current running one to /boot/kernel.old (replacing the one that's already there if it exists) and then extracts the new kernel into /boot/kernel/. This way if something is wrong or incompatible with the new kernel, you can boot the old one. I have defined in the OPNsense build tools to move the kernel to /boot/kernel.vep1400 when it's building the images for the VEP1400/Edge 610 and to include a loader.conf.local file that forces the FreeBSD loader to *always* boot the kernel.vep1400 kernel and to provide the hints (FreeBSD kernel variables) that instruct the kernel on where to find the Marvell switch chip.
The only kernel modification that I did was to use the patch labeled "ixgbe: add MDIO bus support" from the official FreeBSD repo/discussion board here. I think, if memory serves, FreeBSD 16 is supposed to include this code by default, so, when OPNsense gets around to using 16 (maybe 27.1 or 27.7; I can't say for sure (they haven't made any announcements/roadmaps about it), but to be fair, 16 is still in pre-release I think), unless they turn if off, these boxes will just work without any kernel patching and pinning(still need a loader.conf.local though for the switch hints).
On that topic, another recommendation to reduce wear on the eMMC, turn on the RAM disks for log and tmp (here under System, Settings, Miscellaneous) and set them to 5-10% (since you don't have a lot of RAM). If you get that M.2 adapter and put a proper SSD in there, you can leave these off.
One other recommendation, set these tunables (and reboot) to switch the kernel into multi-threaded routing. In your case, you'll want to set them to 2 (or just do like the guide says and set them to -1). Might not matter much for the 610, since the guides I've seen say this is really important for multi-gig routing, but couldn't hurt. And if somehow it does, just delete them and reboot.
More info here.
Last edited:
