Watchguard Firebox 2 Firebox 3 Front LED Panel Daemon
-
Its great stuff & Thanks ;D
I download fbled-bsd and fbled-bsddbg. They are running in my test box Firebox II (pfSense 2.0 RC nanobsd) from a CF showing
S[.**…..] L[….....] T[….....] 3[….....].
I think both of them are running in debug stage. Would you please update your download page of fbled-bsd to LED version and upload the source code also.Thanks again for your contribution.
-
Is it not on github?
The led driving version looks like it's there:
https://github.com/fmertz/fbled/downloads#download_100802Steve
-
yes, I download from there.
BTW, I have modified fbled version 0.1.1.0 (for DD-WRT) source C code before and made it worked on FBII pfsense 2.0 RC. It initiate the LEDs one by one properly and 'System' LED light up finally. For me, it is hard to extract FreeBSD OS data to post the 'Traffic' and 'Load' LED because I am not a C guy.
-
I updated the second post with the status. At this point, we have an extra feature supported: the triangle tips. The idea is to have users configure the firewall to log whatever packet they want. When pf logs these packets, they are sent to the pflog0 device by default, and fbled can capture them from there. If the packets being logged happen to involve dc<n>, the corresponding LED is blinked.
Under FreeBSD, i followed this:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.htmlAnd then: http://www.openbsd.org/faq/pf/logging.html
PS: At this point, the source code is getting ready to be released. I am trying to complete the port of my original Linux code to FreeBSD the "proper" way, using autoconf and automake. I am not quite at a point where the source just compiles under all combinations, but it is not too far off.
Let me know of any progress. I would love for this project to eventually result in a proper package so folks can just use it in pfSense without headache. A word of caution: this has been made and tested under FreeBSD 8.2, I have not quite managed to test it under pfSense, or on the real hardware.</n>
-
fbled-bsd is working.
My interface assigned dc0-WAN, dc1-LAN, dc2-OPT1. 'LOAD' led getting full and 'TRAFFIC" getting 80% to 100% led light up when I start download from OPT1. CPU idle is 0 from 'top'. I thinking it is full of loading there.
The left and top triangle are blinking sometime.
-
Great, glad this is working out. Thanks for helping out in the testing.
Not sure I fully grasped your post: is LOAD working right? It should be 1 LED for 0.15 of load, and 1 more LED each time it doubles (.15->1 LED, .30->2, .60->3, 1.2->4…). As you said, you can use 'top' to get the load number. Easiest to load is: 'openssl speed &' multiple times.
For TRAFFIC, it is the sum total of the number of packets per second on all 3 dc <n>interfaces. Kind of harder to really compute as there is a time factor to it, but a WAN download at 1MBps should give you a few LEDs. Again, it is packets per second, not bits/bytes per second.
For STATUS, SYS A should be on, and ARMED should blink.
For the tips, run 'ifconfig' to confirm there is a pflog0 device. Also, run 'pfctl -s rules' to list the firewall rules, and check if any of them have "log" in them. Every time a packet hits that rule, a blip occurs if it involves one of the dc<n>.
PS: I have a Firebox III, and this all works for me under Linux. I know for a fact that Firebox II's have a slightly different implementation for the control register to the LEDs, so I have not completely ruled out LED bugs just yet. Thanks for letting me know if your box behaves exactly as described above.</n></n>
-
The LEDs worked as you described. Only one led of SYS A or STATUS was turned on (I can't remember which one, will test it again later). ARMED was blinking correctly. 2 blip occurred on triangle.
I tested it from a Celeron 1.2MHz PC client and made 3 BT sessions download. The TRAFFIC and LOAD LEDs were ascending from one LED to full. It was almost over kill FBII (running at AMD K6-2 400 with 256MB), 'top' at putty ssh stopped to refresh anymore and BT download speed at about 1.5MB/s max on 100Mbp WAN link ( ISP claimed).
I will check ifconfig to cheek pflog0 device and pfctl rule log.
PS: I will test the performance when compare with Fortigate 100 for interest.
-
Hi again,
There was not STATUS LED on my FBII box (duno others model). ARMED was blinking and SYS A stayed. More TRAFFIC and LOAD LEDs lit up while packets flowed and cpu became busy.
I captured ifconfig and a few lines of 'pfctl -s rules'.
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
nd6 options=3 <performnud,accept_rtadv>pflog0: flags=100 <promisc>metric 0 mtu 33200
enc0: flags=0<> metric 0 mtu 1536pass in quick on dc1 inet proto udp from 192.168.10.0/24 to 192.168.10.254 port = domain keep state label "USER_RULE: Allow DNS"
pass in quick on dc1 inet proto tcp from 192.168.10.0/24 to 192.168.10.254 port = ntp flags S/SA keep state label "USER_RULE: NTPd service"
pass in quick on dc1 inet proto udp from 192.168.10.0/24 to 192.168.10.254 port = ntp keep state label "USER_RULE: NTPd service"
pass in quick on dc1 inet proto tcp from 192.168.10.0/24 to any port = http flags S/SA keep state label "USER_RULE"
pass in quick on dc1 inet proto tcp from 192.168.10.0/24 to any port = https flags S/SA keep state label "USER_RULE"</promisc></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast> -
There was not STATUS LED on my FBII box (duno others model).
ARMED was blinking and SYS A stayed.
pflog0: flags=100 <promisc>metric 0 mtu 33200</promisc>By STATUS, I meant the stack with SYS A, SYS B, ARMED, DISARMED, so it seems all good.
There definitely seems to be a pflog0 device, so that part seems right.
Without necessarily disclosing your firewall rules, are there any rules with "log" in them? ("pfctl -s rules | grep log")
These rules, when hit, would cause the tips to blink for a bit.Thanks again for the additional research and testing. At this point, it seems to be working well enough to release the code again. I'll do some minor housekeeping and update github.
FWIW, I have not seen this program come up in top with anything in terms of cpu utilization. I have tried to keep it as low load as possible from a code perspective, so I am hoping it is not the cause of the box's high cpu. Under Linux, I even tried and look at slowing down the refresh rate of the LEDs under high load, but the "worker" procedures were running quicker than precision of the clock function I was using. I then figured it was not really worth it. Got to love C code…
-
I updated the source on github:
https://github.com/fmertz/fbled
-
https://github.com/fmertz/fbled
The code was updated again: This is a (very) minor code update, no new executables were created.
The source code now checks that the host system is x86. It compiles the LED code if it is, otherwise, it compiles with the emulator (the text "debug" version). This is for completeness, and the fun of having code compiling on all platforms where the OS runs. I have tested Linux/eglibc with ARM, SPARC, PowerPC and MIPS. It should compile and run on non x86 FreeBSD as well, but I don't have anything available to test with. Again, fairly pointless, but fun nonetheless. A Linux SPARC build session goes like this:fcm@NetraX1B:~$ git clone git://github.com/fmertz/fbled.git Cloning into fbled... remote: Counting objects: 83, done. remote: Compressing objects: 100% (72/72), done. remote: Total 83 (delta 44), reused 13 (delta 5) Receiving objects: 100% (83/83), 108.40 KiB, done. Resolving deltas: 100% (44/44), done. fcm@NetraX1B:~$ cd fbled/ fcm@NetraX1B:~/fbled$ ./autogen.sh **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. processing . Running aclocal ... Running autoheader... Running automake --gnu ... configure.ac:9: installing `./install-sh' configure.ac:9: installing `./missing' Makefile.am: installing `./depcomp' Running autoconf ... Running ./configure --enable-maintainer-mode ... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... checking for struct if_data.ifi_opackets... no configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands Now type `make' to compile. fcm@NetraX1B:~/fbled$ make make all-am make[1]: Entering directory `/home/fcm/fbled' CC fbled.o CCLD fbled make[1]: Leaving directory `/home/fcm/fbled' fcm@NetraX1B:~/fbled$ uname -a Linux NetraX1B 2.6.32-5-sparc64 #1 Tue Jun 14 11:30:39 UTC 2011 sparc64 GNU/Linux fcm@NetraX1B:~/fbled$ ./fbled fbled 0.1.3.2 S[..*.....] L[........] T[........] 3[........]
A FreeBSD session goes like this:
[fcm@BSDDev ~]$ git clone git://github.com/fmertz/fbled.git Cloning into fbled... remote: Counting objects: 83, done. remote: Compressing objects: 100% (72/72), done. remote: Total 83 (delta 44), reused 13 (delta 5) Receiving objects: 100% (83/83), 108.40 KiB | 36 KiB/s, done. Resolving deltas: 100% (44/44), done. [fcm@BSDDev ~]$ cd fbled/ [fcm@BSDDev ~/fbled]$ ./autogen.sh **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. processing . Running aclocal ... Running autoheader... Running automake --gnu ... configure.ac:9: installing `./install-sh' configure.ac:9: installing `./missing' Makefile.am: installing `./depcomp' Running autoconf ... Running ./configure --enable-maintainer-mode ... checking for a BSD-compatible install... /usr/bin/install -c ... checking for struct if_data.ifi_opackets... yes configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands Now type `make' to compile. [fcm@BSDDev ~/fbled]$ make make all-am CC fbled.o CCLD fbled [fcm@BSDDev ~/fbled]$ uname -a FreeBSD BSDDev 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386