Watchguard Firebox X Peak platform

stephenw10

Hmm, it's been a while since I took the cover off mine but I don't remember it having any diagnostic LEDs.
Are you sure you don't have an X5500e?
I'll look tomorrow.

Steve

Edit: Wait are they next to the CF card?

WGFX5000

Model:X5000

LED.jpg_thumb

![Motherboard Model.jpg_thumb](/public/imported_attachments/1/Motherboard Model.jpg_thumb)
![Motherboard Model.jpg](/public/imported_attachments/1/Motherboard Model.jpg)

shanon

Thanks Steve for your response on the X700 thread.

I haven't made any further progress on my issue with the X8000 at this stage, but I have been ordering up some diagnostic equipment (POST diagnostic card, MINI PCI VGA adapter. Also a flash programmer / spare chips soon).

I have nil BIOS development experience, but I'm certainly willing to give it a go, should I get some spare time. I've had a look at coreboot (one of the open source BIOS firmware efforts) and at first blush there seems to be a better-than-even chance that I could get something out of it. There's also serial console redirection for most embedded SuperIO chipsets!

I don't expect that the issue will be with the size of the bootable partition or the size of the CF card, however that's something I'd like to experiment with further.

I had also pondered doing a firmware upgrade from the GUI… I'll likely give that a go over this coming weekend on a spare CF card.

I've also compared sector 0 between the original WG installation, v1.2.3RC1 and newer versions. There's not much evident yet -- all end with the MBR signature 0x55AA. There are three different sets of boot code, and different partition layouts. Perhaps the only thing that could be said for the non-working examples at the moment is that the first primary partition is the bootable one, and partitions start on head # > 0. I haven't de-compiled the code yet, but I'm wondering if the early stages of each bootloader may be using different CHS or LBA addressing?

Final piece of speculation for tonight: if I remember correctly, before I put back the lid, the label indicated that my BIOS was v1.1. I think I've seen a label with v1.2 photographed on this forum... perhaps leading credence to a theory that there are different BIOS firmware versions in the wild with slightly different defaults?

stephenw10

The BIOS in the Watchguard box is far more complex than a standard bios. However most of the extra functionality it provides is not necessary to run pfSense.
For example the Watchguard BIOS:

Has code to drive the LCD and read the keypad.
Can choose to boot different things depending on the keypad status
Has a complete copy of RedBoot built into it for restoring the OS remotely.

Clearly none of that is required for pfSense.
I looked at CoreBoot a few times but without external eprom equipment it looked too risky.
I don't think the serial port uses the SuperIO chip (though there are ports on that) it's using the built in ports on the ICH chip 6300ESB. Looking at a datasheet I could be wrong.

Just having two different bios versions would be interesting.
What is yours listed as?
You can see in the first post here that mine is 10/21/2004.

Steve

Edit: Actually I think you're right, it's on the SuperIO chip:


sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console

I must be getting confused with the X-e box. ::)

stephenw10

@WGFX5000

Clearly they should all be green before it boots up.
There is no public documentation to explain what the LEDs do so it's a guessing game. I can try to look at the boot sequence to see when D5 should turn green.
If there is nothing at all on the display then it's not running the bios code (or the display is broken!). In order to run the code it must have a CPU, some RAM and the correctly programmed bios eprom.
Try reseating the CPU and RAM.

Steve

shanon

@shanon:

I had also pondered doing a firmware upgrade from the GUI… I'll likely give that a go over this coming weekend on a spare CF card.

Well, due to a busy week at work and a number of recent lock-ups, I haven't been able to try an upgrade. I suspect one cap of leaking electrolyte and have also had a bit of a thermal issue with the Scythe replacement fans partially failing in the middle of summer.

Earlier in the week I was able to dump the BIOS firmware in-place via the firmware hub using a BSD port of the flashrom program. Haven't had a chance to analyse the file with any particular tool, though, as there wasn't anything quickly to hand for my Mac or Windows machines. Not sure what the build date on the firmware is, however I did check (and pull-up to confirm flash chip part no.) the stick-on label. It did say V1.21 after all. 'strings' didn't find any date in ASCII format, but a quick glance at the dumped image file suggests it intact, and I'll probably load some tools up in a virtual machine in the coming days to delve further.

I'm awaiting arrival of a few parts to debug further – I'll report back any significant findings.

stephenw10

You can open it and poke around in the menu settings with modbin6 in DOS/Windows. It doesn't give access to anything really interesting though. For that you probably need a decompiler and a lot of patience!

Have you ever read this: http://sites.google.com/site/pinczakko/pinczakko-s-guide-to-award-bios-reverse-engineering

I've tried to a number times! ::)

Steve

power_matz

Hi,

I am trying to use the other NIC's of my FireBox as normal Ethernet ports like the ones of a switch/hub.

E.g: my LAN port is port 1, port 0 is WAN. The other ports (2 - 5) should all be the same like the LAN port.
I found some threads where these ports are "bridged" together. Is this the right way?
But then I have difficulties with the DHCP server for example.
Or is it even more simple???

Does anyone here is using the spare ports of a watch guard like I want it to do?

Matthias

stephenw10

Yes, you have to bridge the ports together to use them like that.
The procedure changed slightly between 1.2.3 and 2.0 so I'm not entirely sure but from memory:
You create a bridge interface and then add to it all the interfaces to be bridged. Then you use the bridge interface for your firewall rules and DHCP server.

However you need to be aware that when you do this all traffic flowing between ports on the bridge is screened and filtered by pfSense so it puts a high load on the CPU compared to an external switch.

http://doc.pfsense.org/index.php/Interface_Bridges

Steve

power_matz

Thank you for your answer.
Do you know if this will work also with VLANs and the IGMP proxy?

shanon

Thanks for the link Steve, hadn't read it.

I have a bit of experience in debugging x86 code. I'm okay with assembly / dis-assembly, but haven't tackled anything near as complicated as reversing a full BIOS. Time will likely be my biggest enemy, but I'm keen to go at least a little further with this.

stephenw10

@power_matz:

Do you know if this will work also with VLANs and the IGMP proxy?

You can bridge VLAN interfaces but isn't there some other way you could do this? You really should try to avoid using bridged interfaces if you can. I have used them just as an experiment and because I couldn't otherwise use all the ports on the X-peak! ;) My situation is low traffic though.

I'm not sure about IGMP proxy I don't use it. I can't see why you couldn't use the bridge interface though.

Steve

power_matz

@stephenw10:

I have used them just as an experiment and because I couldn't otherwise use all the ports on the X-peak!

You have to select a kind for all of the interfaces in the bridge (static, DHCP, none etc). What is the appropriate kind if the bridge will be a DHCP one?

stephenw10

The IP address of the bridge will be static, e.g. 192.168.10.1/24.
As opposed to the WAN interface which usually gets it's address from your ISP.

Steve

power_matz

@stephenw10:

The IP address of the bridge will be static, e.g. 192.168.10.1/24.
As opposed to the WAN interface which usually gets it's address from your ISP.

Steve

Yes, thats clear. I mean the members of the bridge.

stephenw10

Hmm, I thought I'd run through it myself to be sure and it doesn't work as I remember it. It's not possible to assign an IP to the bridge interface for example. Looking into it….

Ok now I remember the little trick, it's not obvious IMHO.

First assign and enable the interfaces you want in the bridge and set the type to none.
Now go to the bridges tab in Interfaces: Assign:, add a new bridge and add the interfaces to it.
Now (here's the part that I forgot) goto Interfaces: (assign) and add a new interface. It will come up with some interface possibly an unused one. Now change that to bridge0.
Now you can enable that interface set it to static (remember to use subnet /24) and add a DHCP server to it.
Having just done this my experimental LCD driver has locked me out of the box, again, so I can't check it. ::)

Steve

Also you must add firewall rules. By default the filtering is done on the member interfaces but I think you can change that to the bridge interface which would be more useful in my case.

wallabybob

@stephenw10:

It's not possible to assign an IP to the bridge interface for example.

On my pfSense LAN is bridge0, bridge0 has members vr0 and ath0. Bridge0 has an IP address, vr0 and ath0 don't have IP addresses.

stephenw10

Thanks for that.
I see my mistake now. I expected bridge0 to be assigned to an interface after I had created it but that's something you have to do manually.
Seems somehow counter-intuitive to me.

Steve

wallabybob

@stephenw10:

I expected bridge0 to be assigned to an interface after I had created it but that's something you have to do manually.

You might be thinking of pfSense 1.2.x way of bridging: when configuring interfaces they could be "bridged" with another interface. The bridging was not always visible and that could result in misleading reports. In particular, if ath0 was bridged with vr0 (or was it the other way around?) a DHCP request on ath0 was reported as received on vr0. Huh, how did the DHCP request from a wireless client get onto a wired interface? (Or, possibly depending on how I had configured the bridging, how did the DHCP request from a wired client get on the wireless interface?)

The 1.2.x way of configuring bridging had a scaling issue in that it wasn't clear how to bridge more than two interfaces.

I like it that in 2.0 the bridging can be made more visible, you can run DHCP server on a bridge interface and it reports DHCP requests on the bridge interface rather than the wrong physical interface.

I haven't tried it, but I suspect it is possible to (say) create a bridge with members ath0 and vr0, assign vr0 to LAN and enable DHCP server on LAN and get the old behaviour. Experience suggests I would come to regret such a choice.

stephenw10

I completely agree the 2.0 way of doing things makes far more sense conceptually.
After I go to Interfaces: (assign): bridges and add a bridge I expected to see that in interfaces but in fact you have to add another interface and assign the bridge to it. There are no clear instructions that set this out and to me it seems unintuitive. Could be just me. ::)

Steve