We're working on improving support (detection, LEDs for WiFi, port naming/ordering) of Sophos x86-based routers in OpenWrt and between me and @NC1 we don't have a few models. Some of them should be hardware-compatible to what we have, but I'd like to confirm a few details.
If you have access to the following Sophos products and either run OpenWrt on it or can temporarily boot an OpenWrt image from a flash-drive on it, please let me know. These are the models of interest:
SG/XG-125/135 revision 1 only. These are the 8-port models, the product names would be sophos-sg-125r1, sophos-xg-125r1, sophos-sg-135r1, sophos-xg-135r1.
Any revision Sophos x85/x86 models.
Any revision Sophos XG-106/116 models.
Please let me know if you have any of those and either are running OpenWrt or can boot OpenWrt from flash-drive on them.
You wouldn't happen to know how to address the power LED on the case (the wifi LED is attached to the wifi card, but I couldn't get the power LED to react to anything).
I don't think the preinit correctly sets the board_name for ubus call system board for this model, doesn't it? If it already does, what's the output of ubus call system board?
If not, what's the output of:
for file in sys_vendor board_vendor product_name board_name product_version; do
cat /sys/devices/virtual/dmi/id/$file
done
(As you can see I'm running an early version of 22.03). The model string is technically not completely incorrect (again, the device specific commit is responsible), but the aesthetics rubbed me the rwong way and I'm doing
echo "Sophos XG 86w" > /tmp/sysinfo/model
in rc.local. That's why I had to reboot to get the actual info.
P.S.: How far are you taking this X86 firewall appliances specific thing? I have a few devices that are a bit more exotic than the Sophos devices. (Currently struggling with bringing up a member of the Saxa SS5000 series -- Japan has really funky X86-based "UTM" devices let me tell you.)
There's only so much I can do. My goal is to properly identify all of Sophos models, properly assign LEDs and properly enumerate/label ports. It all started with @Hurricos commit for Cisco MX100 showing the way and my desire to fix the incorrect order/labeling of ports on 8-port revision 3 model I have.
Hopefully not completely unrelated: Is there any hope of identifying a board that self-identifies as
{
"system": "Intel(R) Atom(TM) CPU E3805 @ 1.33GHz",
"model": "To be filled by O.E.M. To be filled by O.E.M.",
"board_name": "to-be-filled-by-o-e-m-to-be-filled-by-o-e-m"
}
with the following sys_vendor board_vendor product_name board_name product_version
To be filled by O.E.M.
AMI Corporation
To be filled by O.E.M.
Aptio CRB
To be filled by O.E.M.
(This is a Rohde & Schwarz Cybersecurity[sic] GP-U 50, to all intents and purposes an early contemporary of the Sophos devices.)
The GP-U 100/200 would be easy to identify, as that one has the system name filled in, but the GP-U 50 leaves pretty all markers as to be filled in (Aptio CRB is pretty much the only marker, but that BIOS is (too) commonly used). Unless there is something else that is unique, that one is going to be hard.
There are other files in /sys/devices/virtual/dmi/id/, anything device-specific? If not, my (limited) understanding is that you can build a custom base-files IPK file to set model name and model id and configure network. If you want to include the custom base-files IPK in the images built with image builder, make cure to override the version number in the Makefile.
Only one, perhaps: product_uuid yields 03000200-0400-0500-0006-000700080009
If it's only for myself, I can configure the device (and its model strings) for myself already, that's not the issue. But we're not working towards configuring the devices for ourselves, are we?
@tapper@RaylynnKnight thank you! Shocking to see a difference in device paths between the non-wireless and wireless versions for XG-85. I'll have to retest (and potentially ask for more paths here) some of the other devices.
I also wanted to double-check that on all XG devices you have, the ports are marked LAN/1 WAN/2 DMZ/3 and just 4 and that the OpenWrt enumerates them in the correct order.
Labeling as you described is correct for XG 85w, for the XG 106 there is a minor difference in that 4 is labeled Shared with a line to the SFP cage also labeled 4. I'll have to check if they are enumerated correctly on the XG 106, but I'm positive they are on the XG 85w as I submitted the pull request that added support for the XG 85 and XG 86 devices.