Progress on WatchGuard T-70 hardware

rtober

I recently acquired a used T-70 and I noticed that there's been some discussion over the years on a couple of things related to the hardware but I couldn't find any solutions other than some educated guesses and some physical modifications to the MB related to the LEDs and the 5 port NIC controller that stays off unless a WG OS is booted.

I thought it would be fun to see what my AI agent could help with so I fired it up got connected and started "vibe hacking" with the AI agent helping decode results and provide possible testing code to ferret out how the hardware is really put together. I'll try to post any new results as I burn tokens on discovery efforts.

Short-term goals:

Getting more than just the power LED light to work.
Figuring out the driver base for controlling NIC ports 3-7 (currently not initialized) - without making a cut on the circuit board (I believe that is one of the 'popular' methods for getting that 5 port controller to initialize - but only as a dumb 5 port switch under the single enp4s0 controller chip)
Confirmed a working BIOS password for the InsydeH20 firmware.

There are plenty of posts/how-tos on installing pfSense, etc. - I'm not going to cover that part here. This is just for my hardware discoveries concerning the 5 port switch and the LEDs off the MB after getting Ubuntu Server running on a fresh mSATA card (I'm using the original WG mSATA card as viable driver reference location/searchable solution provider).

I've been spending tokens investigating possible solutions to both and I've gotten successful progress on the LEDS and my AI buddy thinks there's viable solution to getting NIC ports 3-7 back under individual control (for VLANing, whatever). I'm hoping somebody else can take my results and use it to push towards getting these two issues working under a pfSense install (vs. my Ubuntu testing build).

As of today:

I have working LED controller code for each of the 4 lights (power is independent): Attn, Failover, Mode, & Status
My AI has a pretty good idea on how to get the enp4s0 controller initialized and provide independent control over NIC port 3-7 (separate VLANs, etc.) but we haven't gotten it tested just yet.

Results as of today (9/18/26):

01 — Hardware: WatchGuard Firebox T70

Known facts

Item	Value
Model	WatchGuard Firebox T70
Firmware	InsydeH20 BIOS
BIOS setup password	`WatchGuard!`
Console port	RJ45 on the front panel, labelled CONSOLE
Console settings	115200 baud, 8 data bits, no parity, 1 stop bit, no flow control
Linux serial device	`ttyS0` (GRUB `--unit=0`)
Ethernet	8 × 1 GbE RJ45 on the panel, labelled 0–7 — but only 4 controllers visible to Linux; see below
Install target	mSATA SSD in the internal mSATA slot
Video output	None — everything happens over the console port

Ethernet interfaces

Linux sees four controllers, not eight ports:

Interface	MAC	Notes
`enp1s0`	`00:90:7f:04:33:58`	WatchGuard OUI, discrete NIC
`enp2s0`	`00:90:7f:04:33:59`	WatchGuard OUI, discrete NIC — first SSH session came in here
`enp3s0`	`00:90:7f:04:33:5a`	WatchGuard OUI, discrete NIC
`enp4s0`	`00:a0:c9:00:00:00`	Intel placeholder MAC = EEPROM-less controller, almost certainly the uplink to an on-board switch chip serving the remaining front-panel ports

Port label → interface map: 1 → enp2s0 (confirmed). By extension
0 → enp1s0 and 2 → enp3s0 are expected; 3–7 are expected to sit behind the
switch on enp4s0 (WatchGuard's wg_dsa.ko confirms a DSA switch is present)
and would share that one Linux interface until a switch driver is identified.
Still to confirm by moving the cable: 0 → , 2 → , 3 → , 4 → , 5 → , 6 → , 7 → .

The 5-port switch behind `enp4s0` (findings 2026-09-18)

enp4s0 is an Intel I210 backplane variant (8086:1537, SGMII) — its
wire side goes to a Marvell 88E6xxx switch, not a socket. Ports 3–7 show
no link LED at all under Ubuntu: the switch's PHYs stay powered down until
a driver initialises the chip.
Fireware ships mainline DSA: dsa_core.ko, mdio.ko, mv88e6xxx_drv.ko,
plus a glue module wg_dsa.ko (depends: dsa_core; strings find_mdio,
__mdiobus_register, wg_dsa_smi_reg, marvell_reset_slave, param
split_mode). Loaded by /etc/runlevel/2/S21eth. So the switch is managed
over Marvell SMI through the I210's MDIO pins, and wg_dsa only registers
that MDIO bus + platform data for mv88e6xxx.
Feasibility: Ubuntu's kernel has mv88e6xxx with an x86 platform-data probe
(dsa_mv88e6xxx_pdata). Needed: one small out-of-tree module providing an
mii_bus over the I210 MDIC register, taking the I210 SW/FW semaphore so it
coexists with igb, and registering the pdata (conduit enp4s0, ports 3–7).
From Fireware's /etc/runlevel/2/S21eth (T70 branch): load order is
dsa_core.ko → mv88e6xxx_drv.ko → wg_dsa.ko (no parameters) →
/sbin/setmacs; then ethtool -K sw10 rx off tx off on the conduit. wg_dsa
names the conduit sw10 (sw11 for a second chip) and user ports eth4+.
It also disables ACPI GPE17 as an "interim fix before BIOS > v1.2" — moot on
BIOS 1.16, but check /sys/firmware/acpi/interrupts/gpe17 if DSA ever shows
an interrupt storm.
mv88e6xxx identifies the chip from its ID register at probe, so the model
need not be known in advance; the platform data only needs the SMI address
and CPU port number, both readable over the bus once the MDIO bridge exists.
All five Fireware modules (wg_dsa, sled_drv-t70, dsa_core, mdio,
mv88e6xxx_drv) are copied to /home/XXXXX/ on the box for reference.

Front-panel LEDs (mapped 2026-09-18)

Panel layout: a 2×2 block — POWER (green, hard-wired, on whenever the box
has power), ATTN (yellow), MODE (green), STATUS (red) — then the
8×2 NIC link/speed LEDs (bottom = 10/100, top = 1000), then a lone
FAILOVER (yellow) at the far end.

The four controllable LEDs are ordinary Braswell SoC GPIOs on the north
pin community (chv_gpio, ACPI INT33FF:01, the 73-line chip — gpiochip1
on this kernel). WatchGuard's own driver (sled_drv-t70.ko, "Braswell WG GPIO
sled/reset button driver", pins GPIO_DFX_0–8) confirms it. Mainline Linux
already drives these lines, so no extra driver is needed.

`gpiochip1` line	Function	Notes
1	MODE, green
2	NIC / PHY reset	Never drive it. Pulling it low resets every Ethernet port; links only came back after a reboot.
3	ATTN, yellow
5	FAILOVER, yellow
7	STATUS, red
0, 4, 6, 8	inputs	reset button and spares; untested

All five outputs are active-low: 0 = on, 1 = off. The BIOS leaves them
at 1, which is why every LED except POWER is dark after a plain install.

Tooling in this repo: scripts/t70-led (t70-led status on, t70-led all off, t70-led show) and scripts/t70-led.service, which lights MODE at boot
and clears all four at shutdown. Install on the box:

sudo install -m 755 t70-led /usr/local/bin/t70-led
sudo install -m 644 t70-led.service /etc/systemd/system/t70-led.service
sudo systemctl daemon-reload && sudo systemctl enable --now t70-led

Verified 2026-09-18: across a reboot MODE goes dark at shutdown, stays off
through POST/GRUB, and comes back on as the serial console reaches the login
prompt. The same reboot confirmed the serial-console GRUB drop-in survives
apt upgrade.

Two libgpiod pitfalls learned the hard way: gpioget without --as-is
reconfigures lines as inputs (use gpioget --as-is), and gpioset releases
the line when it exits but the level persists — so a "blink" loop leaves LEDs
in whatever state the last write set.

The NCT6779D SuperIO that sensors-detect finds is not involved in the
LEDs;

stephenw10

Nice!

So you have the LEDs working in Linux using the standard GPIO drivers there? But not FreeBSD. Yet?

Yes the switch is configured via the MDIO lines on the internal NIC and those are not exposed by default. What's needed there is a patched igb driver that exposes them.

There are a number of possible sources for that. Watchguard did a GPL code release that included their patches. Several other manufacturers have similar hardware. Velocloud had boxes running something built on OpenWRT and at one time their code was available. Stormsheild have some boxes with switches and their OS is FreeBSD based but I've never seen any of that upstreamed.

rtober

@stephenw10 said in Progress on WatchGuard T-70 hardware:

Nice!

So you have the LEDs working in Linux using the standard GPIO drivers there? But not FreeBSD. Yet?

Yes the switch is configured via the MDIO lines on the internal NIC and those are not exposed by default. What's needed there is a patched igb driver that exposes them.

There are a number of possible sources for that. Watchguard did a GPL code release that included their patches. Several other manufacturers have similar hardware. Velocloud had boxes running something built on OpenWRT and at one time their code was available. Stormsheild have some boxes with switches and their OS is FreeBSD based but I've never seen any of that upstreamed.

Correct, I'm working with Linux at the moment but as soon as I'm done I'll switch over to FreeBSD and see if my Agent can apply what it knows about the hardware under Linux to an equivalent in FreeBSD . It took some testing to ferret out the correct GPIO controller point and then some short code to run individual testing on identified PINs to figure out each assignment. There was one 'boobytrap' on the PINs: if you bring the #2PIN low (0), it 'bricks' the entire NIC controller system and all of the interfaces go completely dead until you reboot lol.

part of the discovery process was installing gpioinfo and then also mounting the original WG mSATA and parsing their driver/configs for anything related to the LEDs:

Then once it had the results of that output, it started running "polling" code snippets to sus out how the PINs work (high/low states):
sudo gpioinfo -c gpiochip1 | sed -n '2,10p'
sudo gpioget --as-is -c gpiochip1 1 2 3 5 7 #Shows the current state of each PIN on that chip (high/low)

#The important part was getting "--as-is" into the gpioget command

Then for testing each PIN:
n=1; sudo timeout 0.5 gpioset -c gpiochip1 $n=0; sudo timeout 0.5 gpioset -c gpiochip1 $n=1; ip -br link | grep enp
#Advance n=X through each PIN# and watch results on the LEDs

That flashed each LED and created the PIN mapping table and from there it took the Agent about 2 minutes to write some quick python driver code to manipulate the LEDs however I want.

My agent thinks the NIC problem is an easy solve as well - apparently the Linux Kernal already has the necessary drivers in place, it's just a matter of getting it activated properly. I'll hopefully have more testing done on that (and the results) in a couple of day:

AI Agent:
WatchGuard didn't write a switch driver — they used mainline DSA. Fireware ships dsa_core.ko, mdio.ko and mv88e6xxx_drv.ko (the mainline Marvell 88E6xxx driver), and wg_dsa.ko depends: dsa_core. Their module is only the glue: find_mdio / __mdiobus_register / wg_dsa_smi_reg — it registers an MDIO bus that talks Marvell SMI through the I210's management pins, then hands the switch to mv88e6xxx with platform data (CPU port = enp4s0, port names; split_mode param). marvell_reset_slave is a soft reset over SMI, which is why the switch PHYs stay dark with nothing driving them.

Why it's feasible on 26.04: Ubuntu's kernel already has mv88e6xxx and dsa_core, and mv88e6xxx has an x86 platform-data probe path (dsa_mv88e6xxx_pdata) for exactly this "no device tree" case. What we'd write is one small out-of-tree module, DKMS-built, ~300–400 lines of C:

an mii_bus whose read/write go through the I210's MDIC register (BAR0 + 0x20 — the standard e1000 MDIO engine);
the I210's SW/FW semaphore dance (SWSM / SW_FW_SYNC) around each access, so we share the MDIO engine safely with igb, which polls its own PHY every 2 s — WatchGuard patched igb instead; the semaphore lets us avoid that;
a platform device with dsa_mv88e6xxx_pdata naming enp4s0 as the conduit and ports 3–7.

Result: lan3…lan7 appear as real interfaces, each with its own link state, bridgeable or VLAN-able individually.

Unknowns still on the disk — grab these now while it's mounted, they finish the picture (which Marvell chip, SMI address, port order):

sudo cat /mnt/wg/etc/runlevel/2/S21eth
sudo grep -iE 'switch|dsa|mdio|marvell|88e6' /mnt/wg/etc/product_table.json /mnt/wg/etc/defaultT70.xml | head -20
cp /mnt/wg/lib/drivers/{dsa_core,mdio,mv88e6xxx_drv}.ko ~/
strings ~/wg_dsa.ko | grep -iE '^(eth|lan|sw|cpu|port)' | sort -u | head -20

Then this is a proper design-and-plan job for a fresh session — bigger than the LED tool, but well-bounded. I'll pin it alongside the ATTN task.

stephenw10

Hmm, I never considered a separate driver for the mdio bus. I've no idea how feasible that might be.

FreeBSD doesn't have the DSA and that's a good thing IMO. Far more flexible to actually configure the switch chip and VLANs etc. Though more of a PITA if you do it regularly. But who does that?! Shouldn't be a problem though, it has a driver for the switch.

rtober

Good news at least under Ubuntu:

t70-dsa/1.0, 7.0.0-31-generic, x86_64: installed
enp4s0 UP 00:a0:c9:00:00:00 <BROADCAST,MULTICAST,UP,LOWER_UP>
lan3@enp4s0 UP 00:a0:c9:00:00:00 <BROADCAST,MULTICAST,UP,LOWER_UP>
lan4@enp4s0 LOWERLAYERDOWN 00:a0:c9:00:00:00 <NO-CARRIER,BROADCAST,MULTICAST,UP>
lan5@enp4s0 LOWERLAYERDOWN 00:a0:c9:00:00:00 <NO-CARRIER,BROADCAST,MULTICAST,UP>
lan6@enp4s0 LOWERLAYERDOWN 00:a0:c9:00:00:00 <NO-CARRIER,BROADCAST,MULTICAST,UP>
lan7@enp4s0 LOWERLAYERDOWN 00:a0:c9:00:00:00 <NO-CARRIER,BROADCAST,MULTICAST,UP>
lan3@enp4s0 UP 192.168.10.160/24 metric 100

That's successful NIC negotiation on ports 3-7. Patched in "driver" is working. DHCP address leased. Negotiated at 1GB/s, NIC LEDs on the front indicating as expected.

So that's working LED controller service and a working "patch" to get the p3-p7 drivers initiated and up on the physical/network layer.

I'm going to see if this whole thing can be ported into FreeBSD somehow, so I'll be working on that next and report back with any success/failures.

EDIT: Working on the POE control for p6 & p7 in parallel, that should make it a complete package for the network interfaces.
EDIT2: Looks like POE is hardware controlled and doesn't require anything special to activate (driver wise). There's a special note:
EDIT3: A quick script to read the POE Voltage:
rtober@tobt70:~$ sudo bash ~/t70-poe
input 53.586 V chip 69 °C
port panel power detect class volts mA watts
1 6 on valid PD class 0 53.809 48 2.58
2 7 off open - 0.000 0 0.00
3 - off open - 0.000 0 0.00
4 - off open - 0.000 0 0.00
rtober@tobt70:~$

Running a small Ubiquity G3 POE Camera off p6.

"That settles the spike, and cheaply: Fireware's PoE driver (poedrv-m440.ko) is loaded only for the M440; the T70 tree has no PoE module at all, and the licence files are for T45/T85 (whose PoE is a licensed, software-managed option). So on the T70, PoE isn't software-managed — the PSE controller runs autonomously"

stephenw10

Ooo nice, you have the patch? You might want to post over in the OpenWRT forum. There are a few T70 users over there who could probably use it directly. I one time I had assumed OpenWRT would already support it since Velocloud was using it but for whatever reason it never got upstreamed.

rtober

@stephenw10 said in Progress on WatchGuard T-70 hardware:

Ooo nice, you have the patch? You might want to post over in the OpenWRT forum. There are a few T70 users over there who could probably use it directly. I one time I had assumed OpenWRT would already support it since Velocloud was using it but for whatever reason it never got upstreamed.

ok, I'm working on figuring out how to get this "mod" packaged up into something public on Git that other users can install directly and test further. Right now, it's something that gets injected as part of an "auto-install" configuration when deploying Ubuntu from a USB stick on my private build. I'll drop a post on OpenWRT side and see if anybody is interested.

In the meantime, AI has a plan for trying to convert this over to a pfSense build so I'm working on that stage next. I should have time later in the week to wipe and start with a fresh pfSense install (I've used it as a home lab firewall for years in the past) and then we can see if there's a similar solution for FreeBSD!

rtober

Public Ubuntu repo is up as v1.0.0.0:
https://github.com/rtober/t70-linux/tree/main

Starting the dev plan for the attempted port over to pfSense/FreeBSD

stephenw10

Nice!

rtober

I've got successful LED control figured out. Survives a reboot. pfSense CE 2.9.0 (no additional packages) install on the T70

AI Agent summary:

A reinstall only restores config.xml. Configuration Restore brings back that one file and nothing else — anything in /usr/local is gone. So a normal install would have to be redone by hand after every reimage.
An rc.d service never starts at boot on pfSense anyway. This is the one we discovered the hard way in Task 7. /etc/rc sources /etc/pfSense-rc and then exit 0, so the stock FreeBSD rcorder/localpkg pass never runs — and pfSense-rc doesn't enumerate /usr/local/etc/rc.d at all. rcorder still lists your script when you run it by hand, which is what makes it look correctly installed. We had t70ledd_enable=YES set, the service started fine manually, and it simply never came back after a reboot.

So the payload isn't a convenience for surviving reinstalls. It's the only mechanism that starts the daemon at all.

How
At deploy time, New-LedPayload tars and gzips the eight files, base64-encodes them into one line, and New-ConfigXml injects a shellcmd into system carrying that blob. At boot, pfSense runs it:

The command decodes the base64 with the box's own python3.11, pipes it into tar -xzf -, installs the files to their real locations, then sysrc + service t70ledd start.

Net effect: config.xml alone reconstructs the entire install. We proved it by deleting every installed file, rebooting, and watching all eight come back.

Two things worth remembering
The panel is dark for the first ~57 seconds. shellcmd runs late, after "Bootup complete". I briefly misread that as failure when I checked at 39s. earlyshellcmd (rc.bootup:202) would fire sooner, but before the filesystem and interfaces are ready.

The payload is ~58% of config.xml — 12,268 base64 chars in a 21KB file. Large as a fraction, trivial in absolute terms for a file read once at boot.

stephenw10

Bumped your rep level, should be good now.

rtober

@stephenw10 thanks! the spam protection didn't like some embedded greater than/less than brackets around system process names in my original. I stripped them out and replaced with *

stephenw10

Interesting /usr/local/etc/rc.d should work. That used to be the recommended method some time ago. Though recently I've used shellcmds instead, for the M270 switch script for example.

https://docs.netgate.com/pfsense/en/latest/development/boot-commands.html#shell-script-option

stephenw10

You might also choose to use the filer pkg to store scripts in the config if you need to do that.

What files are required there? It's using it's own driver?

rtober

@stephenw10 said in Progress on WatchGuard T-70 hardware:

You might also choose to use the filer pkg to store scripts in the config if you need to do that.

What files are required there? It's using it's own driver?

Nope. Agent determined that we didn't need to bring anything into the box directly. Uses registers directly to control the LEDs (with guardrails against hitting PIN2 and knocking off the entire network stack).

AI Summary:
The whole thing runs on what pfSense CE 2.9.0 already ships.

Why there's no driver: pfSense has no Braswell GPIO driver. chvgpio(4) isn't in the kernel and there are no /dev/gpioc* nodes, so gpioctl is not an option. Rather than build or import a kernel module, chvpad.py mmaps /dev/mem and writes the SoC pad-control registers directly — north pad community at 0xFED88000, PADCTRL0 at 0x4400 + 8 × line, active-low. That's why everything, including t70-led show, needs root: /dev/mem is root:kmem.

What it depends on, all stock:

Dependency/Source

/usr/local/bin/python3.11 (with mmap) ships with CE 2.9.0
/sbin/ifconfig, /sbin/pfctl, /usr/bin/netstat FreeBSD base
dpinger socket + /var/run files pfSense's own gateway monitoring
config.xml parsing Python stdlib xml.etree

The Python modules import only stdlib (mmap, struct, os, socket, subprocess, glob, re, xml.etree) — no pip, no pkg install, nothing from ports. That was deliberate: pfSense discourages pulling packages in, and the on-box python3.11 made it unnecessary.

The one real cost of going register-direct is that line 2 of the same community is the NIC/PHY reset, so a stray write would reset every Ethernet port. Two guards sit in front of that: chvpad writes only lines 1/3/5/7, and the target's PADCTRL0 must match the LED-pad signature (& 0xFFFFFFFC == 0x00118100), which line 2 fails on the TERM_UP bit.

stephenw10

Ah, interesting. We might be able to get that module included. Though writing directly is probably more version independent. Hmm.

Is this code up somewhere?

rtober

@stephenw10 said in Progress on WatchGuard T-70 hardware:

Ah, interesting. We might be able to get that module included. Though writing directly is probably more version independent. Hmm.

Is this code up somewhere?

Not yet, waiting on my switch controller results. Which I should have time to work on in a couple of days. I'll do the same thing I did for the Ubuntu version, I'll get a public repo up on Github and link it here for you either way.

stephenw10

Just for reference it looks to find the gpios OK but you need the gpiobus modules too:

gpio0: <Intel Cherry View GPIO> iomem 0xfed80000-0xfed87fff irq 49 on acpi0
gpiobus0: <GPIO bus (ACPI-hinted)> on gpio0
gpioc0: <GPIO controller> at pins 0-55 on gpiobus0
gpio1: <Intel Cherry View GPIO> iomem 0xfed88000-0xfed8ffff irq 48 on acpi0
gpiobus1: <GPIO bus (ACPI-hinted)> on gpio1
gpioc1: <GPIO controller> at pins 0-58 on gpiobus1
gpio2: <Intel Cherry View GPIO> iomem 0xfed90000-0xfed97fff irq 50 on acpi0
gpiobus2: <GPIO bus (ACPI-hinted)> on gpio2
gpioc2: <GPIO controller> at pins 0-23 on gpiobus2
gpio3: <Intel Cherry View GPIO> iomem 0xfed98000-0xfed9ffff irq 91 on acpi0
gpiobus3: <GPIO bus (ACPI-hinted)> on gpio3
gpioc3: <GPIO controller> at pins 0-54 on gpiobus3
gpiobus3: invalid pin 0x51, max: 0x36 (bad ACPI tables?)
[2.9.0-RELEASE][admin@t70.stevew.lan]/root: ls /dev/gp
gpioc0% gpioc1% gpioc2% gpioc3% gpt/    
[2.9.0-RELEASE][admin@t70.stevew.lan]/root: gpioctl
Usage:
	gpioctl [-f ctldev] -l [-v]
	gpioctl [-f ctldev] [-pN] -t pin
	gpioctl [-f ctldev] [-pN] -c pin flag ...
	gpioctl [-f ctldev] [-pN] -n pin pin-name
	gpioctl [-f ctldev] [-pN] pin [0|1]
[2.9.0-RELEASE][admin@t70.stevew.lan]/root: gpioctl -f /dev/gpioc1 -l
pin 00:	1	GPIO_DFX0_PAD<OUT>
pin 01:	0	GPIO_DFX3_PAD<IN>
pin 02:	0	GPIO_DFX7_PAD<IN>
pin 03:	0	GPIO_DFX1_PAD<IN>
pin 04:	1	GPIO_DFX5_PAD<OUT>
pin 05:	0	GPIO_DFX4_PAD<IN>
pin 06:	1	GPIO_DFX8_PAD<OUT>
pin 07:	0	GPIO_DFX2_PAD<IN>
pin 08:	0	GPIO_DFX6_PAD<>
pin 09:	-1	<>
pin 10:	-1	<>
pin 11:	-1	<>
pin 12:	-1	<>
pin 13:	-1	<>
pin 14:	-1	<>
pin 15:	0	SEC_GPIO_SUS11_PAD<IN>
pin 16:	0	GPIO_SUS4_PAD<>
pin 17:	0	SEC_GPIO_SUS8_PAD<>
pin 18:	1	GPIO_SUS2_PAD<OUT>
pin 19:	0	GPIO_SUS6_PAD<>
pin 20:	0	CX_PREQ_B_PAD<IN>
pin 21:	0	SEC_GPIO_SUS9_PAD<>
pin 22:	0	TRST_B_PAD<IN>
pin 23:	0	TCK_PAD<>
pin 24:	0	PROCHOT_B_PAD<IN>
pin 25:	1	SVID0_DATA_PAD<OUT>
pin 26:	1	TMS_PAD<OUT>
pin 27:	0	CX_PRDY_B_2_PAD<>
pin 28:	-1	<>
pin 29:	-1	<>
pin 30:	0	SVID0_ALERT_B_PAD<>
pin 31:	0	TDO_PAD<>
pin 32:	1	SVID0_CLK_PAD<OUT>
pin 33:	1	TDI_PAD<OUT>
pin 34:	1	GP_CAMERASB05_PAD<OUT>
pin 35:	1	GP_CAMERASB02_PAD<OUT>
pin 36:	1	GP_CAMERASB08_PAD<OUT>
pin 37:	1	GP_CAMERASB00_PAD<OUT>
pin 38:	1	GP_CAMERASB06_PAD<OUT>
pin 39:	1	GP_CAMERASB10_PAD<OUT>
pin 40:	1	GP_CAMERASB03_PAD<OUT>
pin 41:	1	GP_CAMERASB09_PAD<OUT>
pin 42:	-1	<>
pin 43:	-1	<>
pin 44:	-1	<>
pin 45:	0	GP_CAMERASB04_PAD<>
pin 46:	0	PANEL0_BKLTEN_PAD<>
pin 47:	0	HV_DDI0_HPD_PAD<>
pin 48:	0	HV_DDI2_DDC_SDA_PAD<>
pin 49:	0	PANEL1_BKLTCTL_PAD<>
pin 50:	0	HV_DDI1_HPD_PAD<>
pin 51:	0	PANEL0_BKLTCTL_PAD<>
pin 52:	0	HV_DDI0_DDC_SDA_PAD<>
pin 53:	0	HV_DDI2_DDC_SCL_PAD<>
pin 54:	0	HV_DDI2_HPD_PAD<>
pin 55:	0	PANEL1_VDDEN_PAD<>
pin 56:	0	PANEL1_BKLTEN_PAD<>
pin 57:	-1	<>
pin 58:	-1	<>

Neither module is in a 2.9.0 install by default as you found.

ema81

I've installed ubuntu server (latest) on my Firebox T70, and can confirm that your kernel module and scripts works flawlessly. Can't wait to have them ported to freebsd / pfsense!

Naturally, my test hardware is available for use!

rtober

@ema81 said in Progress on WatchGuard T-70 hardware:

I've installed ubuntu server (latest) on my Firebox T70, and can confirm that your kernel module and scripts works flawlessly. Can't wait to have them ported to freebsd / pfsense!

Naturally, my test hardware is available for use!

Awesome! I believe you are the very first user of my very first public repo!

I'm burning personal tokens on the development so I have to spread it out over the week(s) in-between my other projects, etc. but I've started working on the pfSense port. LED control is sorted and I'm directing my Agent on the draft plan for the networking control.

Progress on WatchGuard T-70 hardware

01 — Hardware: WatchGuard Firebox T70

Known facts

Ethernet interfaces

The 5-port switch behind enp4s0 (findings 2026-09-18)

Front-panel LEDs (mapped 2026-09-18)

The 5-port switch behind `enp4s0` (findings 2026-09-18)