Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Watchguard Firebox 2 Firebox 3 Front LED Panel Daemon

    Scheduled Pinned Locked Moved Hardware
    27 Posts 4 Posters 17.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • I
      ipsec
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • F
        fmertz
        last edited by

        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>

        1 Reply Last reply Reply Quote 0
        • I
          ipsec
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • I
            ipsec
            last edited by

            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 1536

            pass 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>

            1 Reply Last reply Reply Quote 0
            • F
              fmertz
              last edited by

              @ipsec:

              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…

              1 Reply Last reply Reply Quote 0
              • F
                fmertz
                last edited by

                I updated the source on github:

                https://github.com/fmertz/fbled

                1 Reply Last reply Reply Quote 0
                • F
                  fmertz
                  last edited by

                  @fmertz:

                  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
                  
                  
                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.