Random Information ...others might find it interesting too.

Speed up building FreeBSD (-CURRENT / HEAD)

Just some quick notes building -CURRENT / HEAD (FreeBSD 11).



Disables debugging code in malloc, building (and installing) of debug files and also doesn't build 32-bit libs which you most likely doesn't need as you are compiling apps natively (64-bit) anyway.



Set CPU type, gives a nice little speed boost. Do not use native, it will break things (tm).
If unsure which model suits your CPU best read /usr/src/share/examples/etc/make.conf if unsure use core2.
Disable more debugging code and addtional files and don't add profiling data.

Following the regular procedure you might want to use these switches to automatically remove old files.

make -DBATCH_DELETE_OLD_FILES delete-old
make -DBATCH_DELETE_OLD_FILES delete-old-libs

Remote logging using tcpdump and netcat

Quite useful if you have a low-powered device such as an OpenWRT device or a device that's low on space and need to log.

On the server, a common misunderstanding is that you should use both -l and -p which is wrong.
nc -l 9999 > fullcap.pcap

Client, disables login on ports 22, 53, 80, 443 and 9999.
tcpdump -s 0 -U -n -w - -i eth0.2 port not 9999 and port not 53 and port not 80 and port not 443 and port not 22 | nc 9999

Multiple SIP/VoIP devices behind NAT


So, I've been tasked with deploying SIP/VoIP to a small number of offices and it's been working out fairly well except that if you install several devices in my case Gigaset C610IP devices and/or Snom 821 they have been issues answering calls from time to time. I've been troubleshooting this for some time now as it only happens what seems randomly even though they get calls all day long. Interestingly enough making calls have been working fine. There are lots of reports and what seems to be random suggestions on how to fix these issues some which are totally wrong. Thankfully I've seen to nailed it down so I'm going to cover the common misinformation about this.


  • SIP/VoIP ALG is bad do NOT use
  • Proxies are not your solution 2015, they will usually make things worse
  • NAT keep-alive only helps if you have one device in total
  • QoS will not help if you're maxing out your download capacity
  • Keep your device(s) up to date (install firmware updates!), this will help tremendously
  • STUN doesn't really work reliably for VoIP/SIP and only seems to be a way for the device to figure out its external IP (which it will anyway unless its really old and buggy)
  • Changing codecs will not fix anything else than audio quality (unless you're enforcing unsupported ones)
  • PC clients (Mitel) seems to work with NAT much better without pretty much any interraction despite what the Internet says

More detailed information on why -insert bullet point- is bad

While Linux does have a SIP/VoIP connection tracker it modifies packets in a way that isn't RFC-compliant meaning that any model that's ~5 years old and newer will work properly with these enabled. Some router distributions ships these enabled by default (OpenWRT doesn't for instance) so make sure these are not loaded as it's the only way to disable these functions. Your device will figure out by itself if it's behind NAT or not due to how the SIP protocol works, try not to outsmart it.

These can be good in various situations but SIP/VoIP is usually not one of them, in all honestly I never god one to work properly with these phones at all.

Interestingly enough this seems to work on netfilter if you have one device but if you have several which all try to use port 5060 by default this makes things unreliably, that said it worked a lot better using netfilter than pf. Without going into deep packet inspection due to how UDP works in general it makes it hard for the connection tracker figuring out where packets should go and SIP/VoIP devices aren't forgiving at all.

QoS only controls egress traffic, at best your could start dropping packet that already hit your connection but that would be inefficient and doesn't make any sence. QoS is however highly recommended to deploy especially if you're on a cable or DSL connection.

While most vendors actually have some kind of auto update functionality it doesn't seem be triggered automatically in general, just make sure you're running the latest release/stable firmware available which will usually save you from unnecessary odd bugs.

For whatever reason STUN doesn't work as intended on neither of my firewalls. It wont help your data (RTP) connections either so I'm not sure what the intention were adding the functionality in the first place.

Mitel software clients (usually rebranded) seems to work just fine, I have no idea why but say they say... Don't try to fix what aint broken.

Getting your devices to work properly

  • Assign static IPs (otherwise you'll have fun issues and portforward will stop working), locked by MAC address if you're using DHCP as the rest of us 2015.
  • Forward 2 ports per device for SIP protocol control traffic (SIP secure uses +1), common practices are 5060+1 (device 1), 5062+1 (device 2) 5063+1 and so on.
  • RTP needs 2 ports per call, however 19 ports seems to be the unwritten standard and works well. Usually you start at 10000-10018 (UDP) and work your way up.
  • Enable NAT keep alive and make your your timeouts are longer than the actual NAT keep alive timer. In my case our service provider use 90 secs, OpenWRT uses 60 as default so that wont work. Running Linux this goes into /etc/sysctl.conf:

That seems to good enough in most cases, be aware that this may cause issues if you're using DHT protocols which usually are deployed by P2P applications.

  • G.711 is unfortunately standard
  • G.729(ab) is nicer on paper but it's covered with patents so it's a cost issue.
  • G.722 however isn't and would provide a much nicer audio quality over G.711 however very few providers support this codec. This is the one you usually see mentioned/branded as "HD Audio" in VoIP/SIP documentation.

As a sidenote, there are multiple SIP attackers out there so it's wise to only allow your providers netblock on the data connections (5060, 5062 etc).

Good luck!

OpenWRT on the Iomega iConnect


I found these at sale about 3 years back and did a quick search about these boxes and it turns out that they are pretty decent hardware. Unfortunately these didn't get too useful as routers shortly after became more powerful and my intention quickly lost focus in favour to the routers. The iConnect was released back in 2000 and recieved updates the following 2 years so the firmware isn't exactly "fresh". I did however setup one as a NAS about 2 years back and it's been doing fine but the software is getting really dated. I did however make short (and cryptic) notes about how to flash this thing using OpenWRT.


  • USB flash drive (128Mbyte minimum) - FAT16 or FAT32
  • OpenWRT U-Boot and image (openwrt-kirkwood-iconnect-u-boot.kwb , openwrt-kirkwood-iconnect-rootfs.ubifs) - Copied on the flash drive
  • Serial to USB (TTL) adapter, or a native serial port
  • Philips-head screwdriver
  • Terminal app such as PuTTY


  • Open the case (one screw under each rubber pad)
  • Gently pry the case open (no tools needed)
  • Connect your serial cable/adapter (115200 baud)
    Pinout: 1 (near the end): VCC, 2 TX (connect RX), 3 GND, 4 RX (connect TX)
  • Copy u-boot and image to the USB flash drive


  • Enter U-Boot
  • Save the MAC address (ethaddr)
U-Boot 2010.09 (Feb 16 2012 - 03:17:03)
Iomega iConnect Wireless

SoC:   Kirkwood 88F6281_A0
DRAM:  256 MiB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0
Marvell>> printenv
bootcmd=${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; ${x_bootcmd_usb}; bootm 0x6400000;bootdelay=3 baudrate=115200 x_bootargs=console=ttyS0,115200 mtdparts=orion_nand:1M(u-boot),3M@1M(kernel),32M@4M(rootfs),475M@36M(data)x_bootcmd_kernel=nand read 0x6400000 0x100000 0x300000
x_bootcmd_kernel=nand read 0x6400000 0x100000 0x300000
x_bootcmd_usb=usb start
x_bootargs_root=root=/dev/mtdblock2 rw rootfstype=jffs2

Environment size: 481/131068 bytes
  • Start the USB subsystem
    usb start
(Re)start USB...
USB:   Register 10011 NbrPorts 1   
USB EHCI 1.00   
scanning bus for devices... 3 USB Device(s) found   
       scanning bus for storage devices... 1 Storage Device(s) found
  • Load U-Boot into memory
    mw 0x0800000 0xffff 0x100000 ; fatload usb 0 0x0800000 openwrt-kirkwood-iconnect-u-boot.kwb
reading openwrt-kirkwood-iconnect-u-boot.kwb
456776 bytes read
  • Delete currently installed U-Boot
    nand erase 0x0 0x100000
NAND erase: device 0 offset 0x0, size 0x100000
Erasing at 0xe0000 -- 100% complete.
  • Write loaded U-Boot
    nand write 0x0800000 0x0 0x100000
NAND write: device 0 offset 0x0, size 0x100000
 1048576 bytes written: OK
  • Restart

  • Boot into U-Boot again

  • Reset settings to default
    env default -a

## Resetting to default environment
  • Set MAC-address (your own)
    setenv ethaddr 00:D0:B8:0D:FF:FF

  • Save

Saving Environment to NAND...
Erasing NAND...
Erasing at 0xe0000 -- 100% complete.
Writing to NAND... OK
  • Wipe firmware arena
    nand erase 0x200000 0x1fe00000
NAND erase: device 0 offset 0x200000, size 0x1fe00000
Erasing at 0x1ffe0000 -- 100% complete.
  • Create flash UBIFS
    ubi part root ; ubi remove rootfs ; ubi create rootfs
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: empty MTD device detected
UBI: attached mtd1 (name "mtd=3", size 510 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 4080, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
UBI: available PEBs: 3996, total reserved PEBs: 84, PEBs reserved for bad PEB handling: 80
Volume rootfs not found!
No size specified -> Using max size (515579904)
Creating dynamic volume rootfs of size 515579904
  • Start the USB subsystem
    usb start
(Re)start USB...
USB:   Register 10011 NbrPorts 1   
USB EHCI 1.00   
scanning bus for devices... 3 USB Device(s) found   
       scanning bus for storage devices... 1 Storage Device(s) found
  • Load firmware and write to NAND (one line)
    fatload usb 0 0x800000 openwrt-kirkwood-iconnect-rootfs.ubifs ; ubi write 0x800000 rootfs ${filesize}
reading openwrt-kirkwood-iconnect-rootfs.ubifs
22579200 bytes read in 1179 ms (18.3 MiB/s)
22579200 bytes written to volume rootfs
  • Lastly reboot

All set! Happy hacking

How to block outgoing connections by default in OpenWRT using LuCI


For some reason this common operation is undocumented and I'm quite sure I'm not the only one who wants to do this. I did try using the Zones section although that resulted in no traffic going anywhere.
Keep in mind that you still need to have firewall rules in place above this line if you want any outgoing traffic to be passed out such as http etc.


  • Login and navigate using the Menu: Network --> Firewall and after that Traffic Rules
  • Go to "New forward rule:", name it WAN Block or whetever you prefer.
  • Enter the rest as below:
Restrict to address family: IPv4 and IPv6
Protocol: TCP + UDP
Match ICMP type: any
Source zone: lan
Source MAC address: any
Source address: any
Source port: any (empty)
Desination zone: wan
Destination address: any
Distination port any (empty)
Action: reject
  • Done

Remember that it should always be placed last.

OpenWRT on the Ubiquiti Networks EdgeRouter Lite


As the EdgeRouter doesn't seem to get any love (QoS) on the FreeBSD project I decided to have a look at other software solutions and as I've previously have good experience with OpenWRT I decided go with it a try. Information is pretty sparse at the moment but I decided to write a few lines on how you write a bootable USB flash stick on FreeBSD. This actually fits within 128M but as I have no USB flash drives that small I ended up grabbing the smallest one I could find which was a 8Gb thumb drive. Do note that this does not need any modification of u-boot.


  • USB Flash drive (128Mbyte minimum)
  • OpenWRT image (openwrt-octeon-erlite-sysupgrade.tar)


  • Plug in the drive and run dmesg, at the end you'll see something like this
ugen3.2: <Verbatim> at usbus3
umass0: <Verbatim STORE N GO, class 0/0, rev 2.00/1.00, addr 2> on usbus3
umass0:  SCSI over Bulk-Only; quirks = 0xc100
umass0:10:0: Attached to scbus10
da8 at umass-sim0 bus 0 scbus10 target 0 lun 0
da8: <Verbatim STORE N GO 1.00> Removable Direct Access SCSI-2 device
da8: Serial Number 1226000000009999
da8: 40.000MB/s transfers
da8: 7645MB (15656960 512 byte sectors: 255H 63S/T 974C)
da8: quirks=0x2<NO_6_BYTE>
  • Let's have a look at the partition layout on da8
    gpart show /dev/da8
=>       1  15656959  da8  MBR  (7.5G)
         1        31       - free -  (16K)
        32  15656928    1  fat32  (7.5G)
  • Delete the FAT32 partition which has ID 1 (hence 1 before the filesystem)
    gpart delete -i 1 /dev/da8
  • Verify that it's deleted
    gpart show /dev/da8
=>       1  15656959  da8  MBR  (7.5G)
         1  15656959       - free -  (7.5G)
  • Delete the partition table
    gpart destroy /dev/da8
  • Create a new MBR partition table
    gpart create -s MBR /dev/da8
    da8 created
  • Create a 32Mbyte large partition for the kernel and align it to 1M
    Note: I don't think it matters in this case in terms of performance but why not since we have the space.
    gpart add -a 1M -t fat32 -s 32M /dev/da8
    da8s1 added
  • Just to be sure, make it active (bootable)
    gpart set -a active -i 1 /dev/da8
    active set on da8s1
  • Create a partition for the root filesystem, in this case 256Mbyte but you'll be fine with 64Mbyte if you have space constraints.
    gpart add -a 1M -t linux-data -s 256M /dev/da8
    da8s2 added
  • Generate (format) the FAT partition
    newfs_msdos /dev/da8s1
newfs_msdos: trim 16 sectors to adjust to a multiple of 63
/dev/da8s1: 65416 sectors in 8177 FAT16 clusters (4096 bytes/cluster)
BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 Sectors=65520 Media=0xf0 FATsecs=32 SecPerTrack=63 Heads=255 HiddenSecs=0
  • Extract firmware
    tar xf openwrt-octeon-erlite-sysupgrade.tar
  • Mount the FAT partiton
    mount -t msdosfs /dev/da8s1 /mnt
  • Copy kernel to the FAT partition, you also need to rename it to vmlinux.64
    cp ./sysupgrade-erlite/kernel /mnt/vmlinux.64
  • Unmount the FAT partition
    umount /mnt
  • Write the root filesystem the second partition
    dd if=./sysupgrade-erlite/root of=/dev/da8s2 bs=1M
48+0 records in
48+0 records out
50331648 bytes transferred in 7.267285 secs (6925784 bytes/sec)

All set, just plug it in the EdgeRouter

Home ← Older posts