Watchguard Firebox X Peak platform
-
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, consoleI must be getting confused with the X-e box. ::)
-
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
-
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.
-
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
-
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
-
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
-
Thank you for your answer.
Do you know if this will work also with VLANs and the IGMP proxy? -
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.
-
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
-
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?
-
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
-
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.
-
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.
-
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.
-
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
-
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.
-
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
-
Thank you for the instructions.
After doing all that I see that if the bridge only works if on the interface (re2 in my case) the bridge is assigned is up. If a device on re3 (also a member of the bridge) is the only one then the bridge is offline.
Is the a mistake on my side? -
The bridge should be assigned to a non-physical interface such as OPT2. The members of the bridge are the physical interfaces, re2 re3 etc.
That way bridge itself will always appear as UP.Steve
-
ok, got that.
Do you think one rule for the bridge in the firewall is enough?
I don't have to define for each interface a rule, or?
