May 2013

Servlet mocking with Mockito

When writing custom servlets, it can be quite useful to unit test them.  In my case, I used a combination of testng and mockito.  The basic idea is simple; mock a HttpServletRequest, and a HttpServletResponse and pass them to the custom servlet.  There is a bit more too it, so here’s an example. final HttpServletRequest httpServletRequest = mock(HttpServletRequest.class); when(httpServletRequest.getPathInfo()).thenReturn(“/lineup/world.xml”); final HttpServletResponse httpServletResponse = mock(HttpServletResponse.class); final StubServletOutputStream servletOutputStream = new StubServletOutputStream(); when(httpServletResponse.getOutputStream()).thenReturn(servletOutputStream); final ServletConfig servletConfig = mock(ServletConfig.class); when(servletConfig.getInitParameter(“defaultPool”)).thenReturn(“testpool1”); This sets up an HttpServletRequest, an HttpServletResponse, a ServletConfig where i can pass in parameters that the container would have read from web.xml, and a “StubServletOutputStream”, which is just a convenient wrapper around a ByteArrayOutputStream. My StubServletOutputStream looks like this: public class StubServletOutputStream extends ServletOutputStream { public ByteArrayOutputStream baos = new ByteArrayOutputStream(); public void write(int i) throws IOException { baos.write(i); } } It’s necessary to init() the servlet, something the container would normally do: final MyServlet myServlet = new MyServlet(); myServlet.init(servletConfig); Finally; I invoke my servlet, and check the output: restCacheServlet.doGet(httpServletRequest, httpServletResponse); final byte[] data = servletOutputStream.baos.toByteArray(); Assert.assertNotNull(data); Assert.assertTrue(data.length > 0);

The mystery of uart0

The FDT file for Raspberry Pi, declares UART.  I’ve had quite a bit of trouble understanding how declaring a uart in the FDT results in /dev/tty0 and /dev/cuau0 appearing in /dev/ Here are the relevant lines from the FDT: uart0: uart0 { compatible = “broadcom,bcm2835-uart”, “broadcom,bcm2708-uart”, “arm,pl011”, “arm,primecell”; reg = <0x201000 0x1000>; interrupts = <65>; interrupt-parent = <&intc>; clock-frequency = <3000000>; /* Set by VideoCore */ reg-shift = <2>; }; Eventually this uart device gets bound to the sio driver, and exposed as /dev/cuau0 and /dev/tty0. From the FDT declaration I can see that: There are some declarations of the devices that this uart driver is compatible with It uses irq 65, and the parent interrupt controller is “intc” which is declared in the same FDT There are some registers declared It’s also interesting to note that the uart device is not a child of the gpio device, it’s a child of axi, the bus. There is a clue, in the kernel conf for Pi, here; it declares a uart device and pl011 device uart device pl011 The source tree for the uart devices is at /sys/dev/uart ad pl011 is at /sys/dev/uart/uart_dev_pl011.c. Therefore: The kernel conf file specifies that uart and pl011 need to be compiled into the kernel The FDT file declares that there is a uart and that it’s compatible with pl011. The file /sys/dev/uart/uart_bus_fdt.c, is the uart bus driver for devices with a FDT . When the kernel boots, it will call “probe” on this device.  The code below probes the FDT (via Open Firmware) and will detect that a pl011 is compatible. static int uart_fdt_probe(device_t dev) { struct uart_softc *sc; phandle_t node; pcell_t clock, shift; int err; sc = device_get_softc(dev); if (ofw_bus_is_compatible(dev, “ns16550”)) sc->sc_class = &uart_ns8250_class; else if (ofw_bus_is_compatible(dev, “lpc,uart”)) sc->sc_class = &uart_lpc_class; else if (ofw_bus_is_compatible(dev, “fsl,imx-uart”)) sc->sc_class = &uart_imx_class; else if (ofw_bus_is_compatible(dev, “arm,pl011”)) sc->sc_class = &uart_pl011_class; else if (ofw_bus_is_compatible(dev, “cadence,uart”)) sc->sc_class = &uart_cdnc_class; else return (ENXIO); node = ofw_bus_get_node(dev); if ((err = uart_fdt_get_clock(node, &clock)) != 0) return (err); uart_fdt_get_shift(node, &shift); return (uart_bus_probe(dev, (int)shift, (int)clock, 0, 0)); } So, the UART bus device knows to bind the device that was specified in the FDT, because it matches this string “arm, pl011”. So, the mystery is solved this way: The kernel conf ensures that the uart and pl011 devices are compiled in The FDT declares the uart and declares that its compatible with “arm, pl011” which is a string that pl011 recognizes The hardware configuration that the pl011 needs, it reads via Open Firmware, which in turn reads from the FDT blob If you look at the datasheet for the BCM2835, you will see that there is indeed a Primecell pl011 UART on the chip.   On page 177 of the datasheet there is this: The PL011 USRT is mapped on base adderss 0x7E20100. This address mapping of “0x7e20100” matches what was declared int the FDT above. reg = <0x201000 0x1000>; The reason for the difference between 0x7E20100 and 0X201000 is the I/O mapping on the ARM chip, described on page 6 of the datasheet.

Understanding the Raspberry Pi – FreeBSD gpio device

Recently I found myself wanting to understand how I2C for FreeBSD ARM, on the Pi works.  The first step is to understand the GPIO implementation on Pi, since on a Pi, I2C is implemented on the GPIO. So, here’s the basic summary. Firstly, the FreeBSD source browser is here. In the directory /sys/ is the kernel code for all platforms, and in /sys/sys/ is the core kernel code.  In /sys/sys/gpio.h, you’ll find the header which declares the GPIO API for FreeBSD, which must be supported by all FreeBSD GPIO devices on all platforms. Here’s the important parts: /* GPIO pin states */ #define GPIO_PIN_LOW 0x00 /* low level (logical 0) */ #define GPIO_PIN_HIGH 0x01 /* high level (logical 1) */ /* Max name length of a pin */ #define GPIOMAXNAME 64 /* GPIO pin configuration flags */ #define GPIO_PIN_INPUT 0x0001 /* input direction */ #define GPIO_PIN_OUTPUT 0x0002 /* output direction */ #define GPIO_PIN_OPENDRAIN 0x0004 /* open-drain output */ #define GPIO_PIN_PUSHPULL 0x0008 /* push-pull output */ #define GPIO_PIN_TRISTATE 0x0010 /* output disabled */ #define GPIO_PIN_PULLUP 0x0020 /* internal pull-up enabled */ #define GPIO_PIN_PULLDOWN 0x0040 /* internal pull-down enabled */ #define GPIO_PIN_INVIN 0x0080 /* invert input */ #define GPIO_PIN_INVOUT 0x0100 /* invert output */ #define GPIO_PIN_PULSATE 0x0200 /* pulsate in hardware */ struct gpio_pin { uint32_t gp_pin; /* pin number */ char gp_name[GPIOMAXNAME]; /* human-readable name */ uint32_t gp_caps; /* capabilities */ uint32_t gp_flags; /* current flags */ }; /* GPIO pin request (read/write/toggle) */ struct gpio_req { uint32_t gp_pin; /* pin number */ uint32_t gp_value; /* value */ }; /* * ioctls */ #define GPIOMAXPIN _IOR(‘G’, 0, int) #define GPIOGETCONFIG _IOWR(‘G’, 1, struct gpio_pin) #define GPIOSETCONFIG _IOW(‘G’, 2, struct gpio_pin) #define GPIOGET _IOWR(‘G’, 3, struct gpio_req) #define GPIOSET _IOW(‘G’, 4, struct gpio_req) #define GPIOTOGGLE _IOWR(‘G’, 5, struct gpio_req) So, this defines what a GPIO device looks like to FreeBSD and the ioctls it supports, on all platforms. For the ARM kernel, the source code is in /sys/arm/, and for Raspberry Pi, which based on a Broadcom BCM 2835 chip the kernel sources are at /sys/arm/broadcom/bcm2835/. In /sys/arm/broadcom/bcm2835/bcm2835_gpio.c, you’ll find the implementation which exposes the GPIO device, for a Raspberry Pi.  You should notice that the header “gpio_if.h” is included.  This is a generated file, and the source is in /sys/dev/gpio_if.m.   The important parts of this are here: INTERFACE gpio; # # Get total number of pins # METHOD int pin_max { device_t dev; int *npins; }; # # Set value of pin specifed by pin_num # METHOD int pin_set { device_t dev; uint32_t pin_num; uint32_t pin_value; }; # # Get value of pin specifed by pin_num # METHOD int pin_get { device_t dev; uint32_t pin_num; uint32_t *pin_value; }; # # Toggle value of pin specifed by pin_num # METHOD int pin_toggle { device_t dev; uint32_t pin_num; }; # # Get pin capabilities # METHOD int pin_getcaps { device_t dev; uint32_t pin_num; uint32_t *caps; }; # # Get pin flags # METHOD int pin_getflags { device_t dev; uint32_t pin_num; uint32_t *flags; }; # # Get pin name # METHOD int pin_getname { device_t dev; uint32_t pin_num; char *name; }; # # Set current configuration and capabilities # METHOD int pin_setflags { device_t dev; uint32_t pin_num; uint32_t flags; }; An important piece of code to notice in “bcm2835_gpio.c” is the device driver method “probe”: static int bcm_gpio_probe(device_t dev) { if (!ofw_bus_is_compatible(dev, “broadcom,bcm2835-gpio”)) return (ENXIO); device_set_desc(dev, “BCM2708/2835 GPIO controller”); return (BUS_PROBE_DEFAULT); } This is the method FreeBSD calls to ask the driver if a specific piece of hardware is appropriate for that driver.  The ARM GPIO driver looks for “broadcom,bcm2835-gpio”, which is the exact name defined in the Raspberry Pi FDT. Another method which  if the “attach” method, which initializes the driver and adds it to the bus.  This line gets a “bcm_gpio_softc” struct from the device_t passed by the kernel.  The method “device_get_softc” is forward declared in /sys/sys/bus.h, and implemented in /sys/kern/subr_bus.c struct bcm_gpio_softc *sc = device_get_softc(dev); This method initializes a mutex for the driver: mtx_init(&sc->sc_mtx, “bcm gpio”, “gpio”, MTX_DEF); These macros #define BCM_GPIO_LOCK(_sc) mtx_lock(&_sc->sc_mtx) #define BCM_GPIO_UNLOCK(_sc) mtx_unlock(&_sc->sc_mtx) #define BCM_GPIO_LOCK_ASSERT(_sc) mtx_assert(&_sc->sc_mtx, MA_OWNED) Are used to serialize access in certain methods in the driver. These lines allocate memory and IRQs for the driver, as specified in the FTD: rid = 0; sc->sc_mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); if (!sc->sc_mem_res) { device_printf(dev, “cannot allocate memory window\n”); return (ENXIO); } sc->sc_bst = rman_get_bustag(sc->sc_mem_res); sc->sc_bsh = rman_get_bushandle(sc->sc_mem_res); rid = 0;   sc->sc_irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_ACTIVE); if (!sc->sc_irq_res) { bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->sc_mem_res); device_printf(dev, “cannot allocate interrupt\n”); return (ENXIO); } These lines query the Open Firmware and verify the that device is indeed a GPIO controller, according to the FTD: /* Find our node. */ gpio = ofw_bus_get_node(sc->sc_dev); if (!OF_hasprop(gpio, “gpio-controller”)) /* Node is not a GPIO controller. */ goto fail; These lines set up the initial state of the GPIO controller pins: if (bcm_gpio_get_reserved_pins(sc) == -1) goto fail; /* Initialize the software controlled pins. */ for (i = 0, j = 0; j < BCM_GPIO_PINS – 1; j++) { if (bcm_gpio_pin_is_ro(sc, j)) continue; snprintf(sc->sc_gpio_pins[i].gp_name, GPIOMAXNAME, “pin %d”, j); func = bcm_gpio_get_function(sc, j); sc->sc_gpio_pins[i].gp_pin = j; sc->sc_gpio_pins[i].gp_caps = BCM_GPIO_DEFAULT_CAPS; sc->sc_gpio_pins[i].gp_flags = bcm_gpio_func_flag(func); i++; } sc->sc_gpio_npins = i; bcm_gpio_sysctl_init(sc); Finally, these lines add two devices “gpioc” and “gpiocbus”, and then attach the dev to the main bus device_add_child(dev, “gpioc”, device_get_unit(dev)); device_add_child(dev, “gpiobus”, device_get_unit(dev)); return (bus_generic_attach(dev)); The function “device_add_child” is implemented in /sys/kern/subr_bus.c.  The devices “gpio” and “gpioc” are generic devices, which work for all architectures, and they are in: /sys/dev/gpio/gpioc.c and /sys/dev/gpio/gpiobus.c.  The reason the kernel is able to find them by their device class names “gpio” and “gpiobus” is because they are registered with the kernel via these lines of code in gpioc.c and gpiobus.c. driver_t gpioc_driver = { “gpioc”, gpioc_methods, sizeof(struct gpioc_softc) }; devclass_t gpioc_devclass; DRIVER_MODULE(gpioc, gpio, gpioc_driver, gpioc_devclass, 0, 0); MODULE_VERSION(gpioc, 1); driver_t gpiobus_driver = { “gpiobus”, gpiobus_methods, sizeof(struct gpiobus_softc) }; devclass_t gpiobus_devclass; DRIVER_MODULE(gpiobus, gpio, gpiobus_driver, gpiobus_devclass, 0, 0); MODULE_VERSION(gpiobus, 1); The gpio driver which will finally appear on the Pi as “/dev/gpio0”, includes the header system header “/sys/gpio.h” and implements all its methods via that API, which ultimately comes back to /sys/arm/broadcom/bcm2835/bcm2835_gpio.c.  

Spelunking the FreeBSD ARM FDT

The FDT is the “Flattened Device Tree”, a simple device tree used in embedded FreeBSD, for example on a Pi.  Every architecture has a DTS file, which contains a human-readable list of hardware for that architecture.   For example, the Pi FTD is here.  You should notice that there are declarations for: cpu axi (the system bus) time & watchdog gpio: GPIO dma: DMA controller vc_mbox uart; serial controller sdhci; SD card controller memory display leds; the GPIO leds power regulators In other words, all the hardware in the Pi.  If you look at this datasheet from Broadcom, you should see that the hardware declared in the FDT file is the hardware on the Pi’s SOC chip, the Broadcom BCM2835. In my case, I’m specifically interested in RS-232 using the GPIO pins 14 and 15.  The FDT file contains this: /* UART0 */ pins_uart0_a: uart0_a { broadcom,pins = <14>, <15>; broadcom,function = “ALT0”; }; Which specifies that uart0 binds GPIO pins 14 and 15.   If you look in the datasheet, on page 101, you’ll see that GPIO pins 14 and 15, in ALT0 mode are serial TX and RX respectively. If you have FreeBSD up on a Pi, and you have the /dev/openfirm device compiled in to your kernel, you can find uart0 using /usr/sbin/ofwdump. The output “ofwdump -a” on my Pi shows: root@raspberry-pi:/etc # ofwdump -a Node 0x48: Node 0xf8: system Node 0x150: cpus Node 0x15c: cpu@0 Node 0x18c: axi Node 0x1f8: interrupt-controller Node 0x29c: timer Node 0x344: armtimer Node 0x3bc: watchdog0 Node 0x41c: gpio Node 0x538: bsc0_a Node 0x570: bsc0_b Node 0x5a8: bsc0_c Node 0x5e0: bsc1_a Node 0x618: bsc1_b Node 0x650: gpclk0_a Node 0x688: gpclk0_b Node 0x6c0: gpclk0_c Node 0x6f8: gpclk0_d Node 0x730: gpclk1_a Node 0x768: gpclk1_b Node 0x7a0: gpclk1_c Node 0x7d8: gpclk1_d Node 0x810: gpclk2_a Node 0x848: gpclk2_b Node 0x880: spi0_a Node 0x8c4: spi0_b Node 0x908: pwm0_a Node 0x93c: pwm0_b Node 0x970: pwm0_c Node 0x9a4: pwm1_a Node 0x9d8: pwm1_b Node 0xa0c: pwm1_c Node 0xa40: pwm1_d Node 0xa74: uart0_a Node 0xaac: uart0_b Node 0xae4: uart0_c Node 0xb1c: uart0_fc_a Node 0xb58: uart0_fc_b Node 0xb94: uart0_fc_c Node 0xbd0: pcm_a Node 0xc10: pcm_b Node 0xc50: sm_addr_a Node 0xc9c: sm_addr_b Node 0xce8: sm_ctl_a Node 0xd24: sm_ctl_b Node 0xd60: sm_data_8bit_a Node 0xdb8: sm_data_8bit_b Node 0xe10: sm_data_16bit Node 0xe68: sm_data_18bit Node 0xea8: bscsl Node 0xee0: spisl Node 0xf20: spi1 Node 0xf68: uart1_a Node 0xfa0: uart1_b Node 0xfd8: uart1_c Node 0x1010: uart1_fc_a Node 0x104c: uart1_fc_b Node 0x1088: uart1_fc_c Node 0x10c4: spi2 Node 0x110c: arm_jtag_trst Node 0x1148: arm_jtag_a Node 0x1190: arm_jtag_b Node 0x11d8: reserved Node 0x1238: dma Node 0x12f8: mbox Node 0x1384: sdhci Node 0x1414: uart0 Node 0x14c8: vchiq Node 0x1530: usb Node 0x15e0: hub Node 0x1638: ethernet Node 0x16a0: memory Node 0x16d8: display Node 0x176c: leds Node 0x1790: ok Node 0x17f4: regulator Node 0x18ec: regulator@0 Node 0x1998: regulator@3 Node 0x1a48: aliases Node 0x1a70: chosen The list of devices on my Pi matches the list in the FTD (here). I can also use devinfo to find the devices that are actuallly found in my system.  Here’s the output, with the USB stuff removed: root@raspberry-pi:/etc # devinfo -r nexus0 fdtbus0 simplebus0 intc0 I/O memory: 0x2000b200-0x2000b3ff systimer0 Interrupt request lines: 8 9 10 11 I/O memory: 0x20003000-0x20003fff bcmwd0 I/O memory: 0x2010001c-0x20100027 gpio0 Interrupt request lines: 57 I/O memory: 0x20200000-0x202000af gpioc0 gpiobus0 bcm_dma0 Interrupt request lines: 24 25 26 27 28 29 30 31 32 33 34 35 I/O memory: 0x20007000-0x20007fff mbox0 Interrupt request lines: 1 I/O memory: 0x2000b880-0x2000b8bf sdhci_bcm0 Interrupt request lines: 70 I/O memory: 0x20300000-0x203000ff mmc0 mmcsd0 uart0 Interrupt request lines: 65 I/O memory: 0x20201000-0x20201fff dwcotg0 Interrupt request lines: 17 I/O memory: 0x20980000-0x2099ffff usbus0 uhub0 uhub1 smsc0 miibus0 ukphy0 ukbd0 fb0 simplebus1 If I check the dmesg output I see that I do indeed have a uart0 that FreeBSD found on boot: root@raspberry-pi:/dev # dmesg | grep uart uart0: <PrimeCell UART (PL011)> mem 0x20201000-0x20201fff irq 65 on simplebus0 Verifying with ofwdump: root@raspberry-pi:/etc # ofwdump -p uart0 Node 0x1414: uart0 compatible: 62 72 6f 61 64 63 6f 6d 2c 62 63 6d 32 38 33 35 2d 75 61 72 74 00 62 72 6f 61 64 63 6f 6d 2c 62 63 6d 32 37 30 38 2d 75 61 72 74 00 61 72 6d 2c 70 6c 30 31 31 00 61 72 6d 2c 70 72 69 6d 65 63 65 6c 6c 00 reg: 00 20 10 00 00 00 10 00 interrupts: 00 00 00 41 interrupt-parent: 00 00 00 01 clock-frequency: 00 2d c6 c0 reg-shift: 00 00 00 02 You can see that the data ofwdump returns for uart0 matches with the FTD and with uart0 that FreeBSD reported.  The IRQ that ofwdump returns is 0x41, which is 65 in base-10; exactly what’s expected. If you look at the bottom of the FTD file, you will see that uart0 is bound to stdin and stdout: chosen { bootargs = “”; /* Set by VideoCore */ stdin = “uart0”; stdout = “uart0”; }; There is a description of the “/chosen” node in the FDT here and here from devicetree.org. For more information, there is this excellent presentation, this FreeBSD Wiki page, and this white paper.   There is a wiki here, with quite a lot of good information on Flattened Device Tree. Looking at the /dev/ tree I see: crw——- 1 root wheel 0x1f Apr 27 13:42 ttyu0 crw——- 1 root wheel 0x20 Apr 27 21:42 ttyu0.init crw——- 1 root wheel 0x21 Apr 27 21:42 ttyu0.lock crw-rw—- 1 uucp dialer 0x22 Apr 27 21:42 cuau0 crw-rw—- 1 uucp dialer 0x23 Apr 27 21:42 cuau0.init crw-rw—- 1 uucp dialer 0x24 Apr 27 21:42 cuau0.lock I these devices are the sio device, bound to uart0. /dev/ttyu0 was declared in the /etc/ttys.  The build script here was used to create my Pi install, and the specific line that declares this tty was; ttyu0 “/usr/libexec/getty 3wire.115200” dialup on secure If you’re interested in what “3wire.115200” actually means, it’s declared in /etc/gettytab.  The details of setting up tty devices in FreeBSD are here, in the FreeBSD Handbook.  

restcache

I recently found myself in a situation where mission-critical software was suffering from performance problems due to relying on a remote API which was both slow (as slow as 11sec / transaction), and unreliable.   In this case, it turned out that there were multiple applications accessing this API, and every individual application was affected.  There were some details of the remote API that were notable: It is accessible via RESTful URLs It returns cacheable results It is generally used in a read-only mode So, a reasonable solution appeared to be to write a caching proxy.  The result is restcache. Details of the solution are very simple.  I implemented a Java Servlet which proxies GET and POST requests to a foreign server.  GET requests which do not have query parameters are intercepted and cached using Apache JCS.  JCS is a very mature piece of software which can implement multi-layer caches, and includes features such as disk based caches, relational caches and even in-memory caches. For restcache, it was likely that there would be more that one foreign API which I wanted to proxy-cache, so I implemented cache pools. A cache pool is simply a dedicated JCS region which caches responses from a specific HTTP URL. Finally, real-world caches, on real-world sites, need to be maintained, monitored and occasionally cleared by system admins.  restcache exposes a great deal of data using JMX, and supports clearing pools via JMX.  Any reasonable system administration tool which can communicate with servers over JMX could monitor restcache, or an admin could simply use JConsole. Configuration of caches in restcache is simple: Configure the JCS regions, like this.   The example which matches the XML below is here. Configure the restcache pools in XML.  The schema is here. Here’s an example pool declaration which caches RSS from CBC.  The JCS region it uses is called “cbc”, and is configured in cache.ccf. <rcpool> <name>cbc</name> <region>cbc</region> <target>rss.cbc.ca</target> </rcpool> So, any cacheable GET request to “rss.cbc.ca” will be stored in the JCS region “cbc”.  So this, for example, would be cached. Interestingly, JCS supports lateral caching, so if you really need that, it’s available. Finally, there is an additional potential application; reducing the costs incurred by accessing per-transaction APIs.   Some APIs charge a fee every time the API is accessed.  If those APIs are accessed from a public-facing site, there quickly becomes an issue of cost control.  restcache could be inserted between the costly API and the public facing site with the intention of returning cached results rather than accessing the API for every page render.

Simple pf for Raspberry Pi

One of the best things about the Pi is that it’s small, and portable.  It’s very tempting to use it on wireless networks, unattended.  Sadly, in the real world, any wireless network can be hacked, and any device on wireless should be considered vulnerable.  So, pf is an easy way to harden your Pi. The first thing you’ll need is a FreeBSD Pi install, which has the pf device in the kernel.  You can get that here, or just build yourself a kernel with pf. Then, you will need some simple rules.  I used these rules in the file “/etc/pf.conf” # options set block-policy return set optimization conservative # normalization scrub in all scrub out all # default, deny everything block in log all pass out quick #icmp pass out inet proto icmp from any to any keep state pass in quick inet proto icmp from any to any keep state #ssh pass out inet proto tcp from any to any port 22 keep state pass in quick inet proto tcp from any to any port 22 keep state #localhost pass in quick on lo0 all pass out quick on lo0 all Simply; I block everything other than ssh, icmp (ping). In order to load the rules: pfctl -f /etc/pf.conf and to show the current status of the packet filter: pfctl -s all You’ll want FreeBSD to load your pf rules when it starts, so add the below to “/etc/rc.conf” pf_enable=”YES”