OTA Failure

One of my biggest frustrations is that in order to watch Japanese language television, I need to subscribe to “TV Japan”, which requires $25 monthly, plus the cost of basic “cable” from Verizon. Also, throw in a DVR monthly rental because I usually record and watch programs later at my convenience. While there are streaming services that have some Japanese content, none–that I am aware of–offer Japanese news broadcasts, documentaries, and variety shows.

A few years ago I tried getting a simple UHF/VHF antenna and tried receiving Over The Air (OTA) digital television. This experiment failed miserably as I was too far away from the broadcast towers and the indoor antennas did not have enough gain. Recently, however, I saw a refurbished Mohu Air60 antenna and amplifier bundle with a 60 mile range at the local electronics store. I decided to buy it and install it as a possible way to explore “cutting the cord”. This required mounting it in the attic, and then run coaxial cable from the attic to my television in the basement. That went surprisingly well, and after kicking off the channel scan on my television, I started picking up stations with crystal clear reception.

At first, everything worked beautifully. I received about 40 channels, including two Chinese language stations which was exactly what I was hoping I would be able to receive. I did find it curious that while I could receive NBC and PBS, I was not getting CBS or ABC local stations. After a week though, everything changed for the worst on April 1st. A nearby broadcast station to the southwest turned off its transmitter and I am now only getting 8 channels, most of which I have no interest in at all (westerns, spanish language, old movies, et cetera).

I reached out to Mohu to ask some questions, confirming that the antenna is omnidirectional and that my configuration is correct. It turns out that I live in a dead zone where VHF signals cannot be picked up from the broadcast towers to the east. I am only receiving the UHF stations from the east now that the broadcast southwest of me has shutdown its transmitter. There is no way to resolve this reception issue according to Mohu.

So for the time being, Verizon will continue to get my money…must do more research about streaming possibilities. For Chinese language media, I found KylinTV, which offers Internet-based streaming of Chinese language programs. But for Japanese programs?


Applied FreeBSD: Fibre Channel Target

I wanted to learn about iSCSI and Fibre Channel (FC) but I do not have access to any Enterprise hardware systems that would allow learning. As such, I decided I would build a basic Fibre Channel system.

The most simple Fibre Channel network is a point-to-point system which has just two nodes. The node that serves a storage resource over the network is the Target, and the consumer of the storage resource is the Initiator. I bought two Qlogic 2460 4 Gb/s PCI Express FibreChannel Host Bust Adapters (HBAs) and 15ft. of LC-type fibre cable from Ebay. I downloaded the latest firmware for the devices and updated them using the EFI loader on my workstation. I left one card in my Linux workstation, and put the other in the FreeBSD box.

I have a SATA harddrive in the FreeBSD box that is not currently being used, so the goal will be to serve it over Fibre Channel for the Linux workstation to use. There is not a lot of HOWTO, guides, or general information about Fibre Channel and FreeBSD, but I found Justin Holcomb’s blog to be extremely helpful in getting started.

Configuring a FreeBSD Fibre Channel Target

First of all, /dev/ada1 is the disk drive I want to serve over FC.

root@freebsd:/usr/home/bryan # camcontrol devlist
<TOSHIBA HDWD110 MS2OA8J0>         at scbus0 target 0 lun 0 (ada0,pass0)
<TOSHIBA HDWD110 MS2OA8J0>         at scbus1 target 0 lun 0 (ada1,pass1)
<hp CDDVDW SH-216ALN HA5A>         at scbus2 target 0 lun 0 (cd0,pass2)
<AHCI SGPIO Enclosure 1.00 0001>   at scbus4 target 0 lun 0 (ses0,pass3)

Also, during boot, FreeBSD recognizes my FC card (from dmesg output):

isp0: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0xe000-0xe0ff mem 0xfe440000-0xfe443fff irq 16 at device 0.0 on pci1
isp0: Polled Mailbox Command (0x8) Timeout (100000us) (isp_reset:953)
isp0: Mailbox Command ‘ABOUT FIRMWARE’ failed (TIMEOUT)
isp0: isp_reinit: cannot reset card
device_attach: isp0 attach returned 6

FC is supported by the system, but in order to have the system act as an FC Target, the kernel needs to be compiled with the ISP_TARGET_MODE option (as well as enabled ispfw to load run-time firmware onto the FC HBA. I followed the steps from Justin’s blog:

#mkdir ~/kernels
# touch /root/kernels/FCTARGET
# vim /root/kernels/FCTARGET

Add the following to the FCTARGET kernel configuration file:

include GENERIC
device          ispfw                   #Firmware for QLogic HBAs
options         ISP_TARGET_MODE         #Required for Target Modecd /usr/src

Now build and install the kernel.

# ln -s /root/kernels/FCTARGET /usr/src/sys/amd64/conf/FCTARGET
# make buildkernel KERNCONF=FCTARGET
# make installkernel KERNCONF=FCTARGET
# reboot

After rebooting, the system is ready to be configured in FC Target mode. Modify /etc/rc.conf such that ctld_enable=”YES” is added.

 # sysrc ctld_enable=YES
ctld_enable: NO -> YES

Next, the CAM target layer daemon (ctld) needs a configuration file that will describe what resources to serve. The config below is the most basic configuration, which has no authentication and simply serves the block device over FC port isp0.

# cat /etc/ctl.conf
target  ???????????????? {
alias toshiba-drive
auth-group no-authentication
port isp0
lun 0 {
backend block
# Disk serial number is 671ABKPFS
device-id 671ABKPFS
path /dev/ada1

The “??????????????????” is because I do not know the World Wide Name (WWN) for the FC link. The ctladm command shows the WWN when querying for CAM target layer ports.

# ctladm port -l
Port Online Frontend Name     pp vp
0    NO     camsim   camsim   0  0  naa.50000006f1d1ab01
1    YES    ioctl    ioctl    0  0
2    YES    tpc      tpc      0  0
3    NO     camtgt   isp0     0  0

From the above output, it is clear that isp0 is not online. After reading through the ctladm man page, I found the commands to bring the port online.

# ctladm port -o on isp0
Front End Ports enabled
# ctladm port -l
Port Online Frontend Name     pp vp
0    YES    camsim   camsim   0  0  naa.500000012e445301
1    YES    ioctl    ioctl    0  0
2    YES    tpc      tpc      0  0
3    YES    camtgt   isp0     0  0  naa.2100001b320f1d96

Now the port has a WWN: naa.2100001b320f1d96. The complete ctl.conf file is updated:

# cat /etc/ctl.conf
target  naa.2100001b320f1d96 {
alias toshiba-drive
auth-group no-authentication
port isp0
lun 0 {
backend block
# Disk serial number is 671ABKPFS
device-id 671ABKPFS
path /dev/ada1

Now it is time to start the CAM target layer (CTL) service on the system. Note that if there are any syntax errors in the ctl.conf file, the service will not start and will provide some clues as to where the errors are.

# service start ctld

The service starts without any hiccups and one can now query CTL for status.

# ctladm devlist -v
LUN Backend       Size (Blocks)   BS Serial Number    Device ID
0 block            1953525168  512 MYSERIAL   0     671ABKPFS

Now it is time to configure the Linux system as an FC initiator to test FC link and CTL target service.

Configuring a Linux Fibre Channel Initiator

Good news! This just worked out of the box, no configuration needed. First of all, looking through dmesg output, this RHEL 7 workstation has loaded the driver for the Qlogic card.

[ 1.303534] qla2xxx [0000:04:00.0]-00fc:1: ISP2432: PCIe (2.5GT/s x4) @ 0000:
04:00.0 hdma+ host#=1 fw=8.06.00 (9496).

Further down in the output, there is more activity with the qla2xxx driver:

[281614.649436] qla2xxx [0000:04:00.0]-500a:1: LOOP UP detected (4 Gbps).
[283199.887749] qla2xxx [0000:04:00.0]-500b:1: LOOP DOWN detected (2 5 0 0).[283202.700162] qla2xxx [0000:04:00.0]-500a:1: LOOP UP detected (4 Gbps).[283202.711117] scsi 1:0:0:0: Direct-Access     FREEBSD  CTLDISK          0001 PQ: 0 ANSI: 7
[283202.721738] scsi 1:0:0:0: alua: supports implicit TPGS
[283202.722115] scsi 1:0:0:0: alua: port group 01 rel port 03
[283202.722342] scsi 1:0:0:0: alua: rtpg failed with 8000002
[283202.722343] scsi 1:0:0:0: alua: rtpg sense code 06/29/01
[283202.722344] scsi 1:0:0:0: alua: not attached
[283202.722507] sd 1:0:0:0: Attached scsi generic sg3 type 0
[283202.722732] sd 1:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[283202.722734] sd 1:0:0:0: [sdc] 4096-byte physical blocks
[283202.723335] sd 1:0:0:0: [sdc] Write Protect is off
[283202.723336] sd 1:0:0:0: [sdc] Mode Sense: 7f 00 10 08
[283202.723483] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
[283202.727281] sd 1:0:0:0: [sdc] Attached SCSI disk

The FC loop has gone up, which was explicitly done on the FreeBSD server. At this point, the system negotiates the FC protocol and the remote drive is now handed over to the SCSI subsystem, where is becomes /dev/sdc.

That is all there is to it, fdisk or parted can now be used on the Linux workstation to partition the remote disk and put a filesystem on the disk. For fun, there is a useful utility systool that  can be used for learning about FC devices on the system.

# yum install sysfsutils -y
# systool -c fc_host -v host1
Class = “fc_host”
Class Device = “host1”
Class Device path =
dev_loss_tmo        = “30”
fabric_name         = “0xffffffffffffffff”
issue_lip           = <store method only>
max_npiv_vports     = “127”
node_name           = “0x2000001b320f368f”
npiv_vports_inuse   = “0”
port_id             = “0x0000e8”
port_name           = “0x2100001b320f368f”
port_state          = “Online”
port_type           = “LPort (private loop)”
speed               = “4 Gbit”
supported_classes   = “Class 3”
supported_speeds    = “1 Gbit, 2 Gbit, 4 Gbit”
symbolic_name       = “QLE2460 FW:v8.06.00 DVR:v8.”
system_hostname     = “”
tgtid_bind_type     = “wwpn (World Wide Port Name)”
uevent              =
vport_create        = <store method only>
vport_delete        = <store method only>
Device = “host1”
Device path = “/sys/devices/pci0000:00/0000:00:1b.4/0000:04:00.0/host1”
fw_dump             =
nvram               = “ISP ”
optrom_ctl          = <store method only>
optrom              =
reset               = <store method only>
sfp                 = “”
uevent              = “DEVTYPE=scsi_host”
vpd                 = “0”


Setting up FibreChannel is even easier than iSCSI, but it does require a kernel recompile on the FreeBSD server. Furthermore, FC requires HBAs on each machine as well as the fibre infrastructure such as switches and fibre cable.

Linux: Burning an ISO to a DVD disc

Brasero is not working for me in RHEL7 Desktop. I downloaded the latest Kali Linux ISO image and I want to burn the ISO to a DVD. When I put a blank DVD into the drive, Gnome shows the blank DVD on the desktop. But for some reason Brasero cannot see the disc. After trying some troubleshooting hacks, I realized that I’d much rather have a method for working with DVD burning from the command line rather than messing around with Brasero, or having to install k3b. It is Linux after all, there ought to be a simple way to do this from the command line.

DVD Hardware Check

First things first, I wanted to check up on my DVD burner hardware and see if it is recognized. My burner is an SATA device from an older HP desktop from which I recovered it.

# dmesg | less

[ 1.305351] ata1.00: ATAPI: hp DVD-RAM GHA3N, RH07, max UDMA/100
[ 1.305611] ata2.00: configured for UDMA/133

[ 8.861738] scsi 2:0:0:0: CD-ROM hp DVD-RAM GHA3N RH07 PQ: 0 ANSI: 5

I also wanted to see if RHEL7 does anything with creating device files for the burner. Various Linux distributions create a /dev/dvd, /dev/cdwriter, etc.  I know that /dev/sr# is the way Linux handles CD/DVD drives. I only have one device, so it should be /dev/sr0.

# ls -l /dev/sr0
brw-rw—-+ 1 root cdrom 11, 0 Feb 4 09:58 /dev/sr0
# ls -l /dev/cdrom
lrwxrwxrwx. 1 root root 3 Feb 4 09:58 /dev/cdrom -> sr0

RHEL7 creates a symlink /dev/cdrom which points to /dev/sr0.

Media Verification

My next question was whether the blank DVD media could be recognized. It turns out that the dvd+rw-tools package has a tool to help with that. If it is not on your system, for CentOS/RHEL, run “yum install dvd+rw-tools”.

# dvd+rw-mediainfo /dev/cdrom
Mounted Media: 1Bh, DVD+R
Media ID: CMC MAG/M01
Current Write Speed: 16.0×1385=22160KB/s
Write Speed #0: 16.0×1385=22160KB/s
Write Speed #1: 8.0×1385=11080KB/s
Write Speed #2: 6.0×1385=8310KB/s
Write Performance: 6.8×1385=9420KB/s@0 -> 16.0×1385=22160KB/s@2295103
Speed Descriptor#0: 02/2295103 R@16.0×1385=22166KB/s W@16.0×1385=22160KB/s
Speed Descriptor#1: 02/2295103 R@16.0×1385=22166KB/s W@8.0×1385=11080KB/s
Speed Descriptor#2: 02/2295103 R@16.0×1385=22166KB/s W@6.0×1385=8310KB/s
Media Book Type: 00h, DVD-ROM book [revision 0]
Legacy lead-out at: 2295104*2KB=4700372992
Disc status: blank
Number of Sessions: 1
State of Last Session: empty
“Next” Track: 1
Number of Tracks: 1
Track State: blank
Track Start Address: 0*2KB
Next Writable Address: 0*2KB
Free Blocks: 2295104*2KB
Track Size: 2295104*2KB
ROM Compatibility LBA: 266544

There is lots of output, but the main point is the “Disc status: blank” and “State of Last Session: empty” which verify the disc is readable and empty.

Wodim – Going down the wrong path…maybe?

When searching for command-line tools to burn ISO images, cdrecord came up frequently. In RHEL7, cdrecord is available and is a symlink to /usr/bin/wodim. Before messing with wodim and disc burning, I thought I’d use to tool to make sure it sees my hardware. After all, Brasero did not see the DVD-RAM drive with an empty disc, and perhaps this will be the same.

# /usr/bin/wodim –devices
/usr/bin/wodim: No such file or directory.
Cannot open SCSI driver!
For possible targets try ‘wodim –devices’ or ‘wodim -scanbus’.
For possible transport specifiers try ‘wodim dev=help’.
For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from
the wodim documentation.

Well, that did not look good. Back to google for more help. On some Ubuntu forums it was recommended to manually instruct wodim to use /dev/sr0.

# wodim dev=/dev/cdrom -checkdrive
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : ‘hp ‘
Identification : ‘DVD-RAM GHA3N ‘
Revision : ‘RH07’
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
Supported modes: PACKET SAO

Much better. But as I was searching further, I came across some information about another utility, growisofs. The name does not sound like a disc burner software, but it turns out that the capability was added over the years.

growisofs – the tool I was looking for

So growisofs does not only burn ISO disc images, it can also be used to create DVD data discs (DVD+R discs) that allow for multiple sessions. At the end of the post I will include some samples for doing so. The focus now is burning an ISO image.

To burn an ISO image, first I added the -dry-run flag so that it only simulates writing to disc. Test first! The next flag is the -dvd-compat flag which makes the disc unappendable. This is what we want for an ISO disc image. Next, the -Z option is used to indicate that this should be the initial session on the disc.  Finally, the ISO disc image is specified and is to be written to /dev/cdrom, which is the symlink to /dev/sr0 on my RHEL7 workstation.

# growisofs -dry-run -dvd-compat -Z /dev/cdrom=/root/kali-linux-2017.3-amd64.iso
😦 growisofs is being executed under sudo, aborting!
    See NOTES paragraph in growisofs manual page for further details.

No bueno. Reading the man page has a long explanation for while performing this operation as root is not necessary. Check the man page if you are interested. Trying again with a regular user account. I made the sure the ISO disc image was readable

$ growisofs -dry-run -dvd-compat -Z /dev/cdrom=/root/kali-linux-2017.3-amd64.iso
😦 unable to open64(“/dev/cdrom”,O_RDONLY): Permission denied

Again, no bueno. Well that is just dandy. The tool does not want to be run via sudo or from the root user account, but my regular user account cannot access the DVD-RAM drive. I bet there is a specific user group for that…checking /etc/group yields a “cdrom” group.

$ ls -al /dev/cdrom
lrwxrwxrwx. 1 root root 3 Feb  4 09:58 /dev/cdrom -> sr0
$ ls -al /dev/sr0
brw-rw—-+ 1 root cdrom 11, 0 Feb  4 09:58 /dev/sr0

Yes, cdrom group owns the DVD-RAM drive, so I need to add my user to that group.

$ sudo usermod -aG cdrom bryan
$ groups
bryan wheel cdrom docker

That’s better. Trying again…

$ growisofs -dry-run -dvd-compat -Z /dev/cdrom=/root/kali-linux-2017.3-amd64.iso
Executing ‘builtin_dd if=/root/kali-linux-2017.3-amd64.iso of=/dev/cdrom obs=32k seek=0’

That output looks promising. After taking away the -dry-run option, I hear the drive spin up and start getting to work:

$ growisofs -dvd-compat -Z /dev/cdrom=/root/kali-linux-2017.3-amd64.iso
Executing ‘builtin_dd if=/root/kali-linux-2017.3-amd64.iso of=/dev/cdrom obs=32k seek=0’

/dev/cdrom: “Current Write Speed” is 16.4x1352KBps.
          0/2886402048 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/2886402048 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/2886402048 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/2886402048 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/2886402048 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/2886402048 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/2886402048 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
    1114112/2886402048 ( 0.0%) @0.2x, remaining 1294:52 RBU 100.0% UBU   2.9%
   23396352/2886402048 ( 0.8%) @4.8x, remaining 67:18 RBU 100.0% UBU 100.0%
   56688640/2886402048 ( 2.0%) @7.2x, remaining 30:46 RBU 100.0% UBU 100.0%
   90505216/2886402048 ( 3.1%) @7.3x, remaining 20:35 RBU 100.0% UBU 100.0%
  124846080/2886402048 ( 4.3%) @7.4x, remaining 15:51 RBU 100.0% UBU 100.0%
  159744000/2886402048 ( 5.5%) @7.6x, remaining 13:22 RBU 100.0% UBU 100.0%
  195198976/2886402048 ( 6.8%) @7.7x, remaining 11:29 RBU 100.0% UBU 100.0%
  231178240/2886402048 ( 8.0%) @7.8x, remaining 10:08 RBU 100.0% UBU 100.0%
  267714560/2886402048 ( 9.3%) @7.9x, remaining 9:17 RBU 100.0% UBU 100.0%
  304775168/2886402048 (10.6%) @8.0x, remaining 8:28 RBU 100.0% UBU 100.0%
  342360064/2886402048 (11.9%) @8.1x, remaining 7:48 RBU 100.0% UBU 100.0%
  379125760/2886402048 (13.1%) @8.0x, remaining 7:23 RBU 100.0% UBU 100.0%
  415105024/2886402048 (14.4%) @7.8x, remaining 6:56 RBU 100.0% UBU 100.0%
  454262784/2886402048 (15.7%) @8.5x, remaining 6:30 RBU 100.0% UBU 100.0%
  493977600/2886402048 (17.1%) @8.6x, remaining 6:12 RBU 100.0% UBU 100.0%
  534249472/2886402048 (18.5%) @8.7x, remaining 5:52 RBU 100.0% UBU 100.0%
  575045632/2886402048 (19.9%) @8.8x, remaining 5:33 RBU 100.0% UBU 100.0%
  616398848/2886402048 (21.4%) @9.0x, remaining 5:20 RBU  99.8% UBU 100.0%
  658243584/2886402048 (22.8%) @9.1x, remaining 5:04 RBU 100.0% UBU 100.0%
  700678144/2886402048 (24.3%) @9.2x, remaining 4:50 RBU 100.0% UBU 100.0%
  743604224/2886402048 (25.8%) @9.3x, remaining 4:39 RBU 100.0% UBU 100.0%
  787087360/2886402048 (27.3%) @9.4x, remaining 4:26 RBU 100.0% UBU 100.0%
  831094784/2886402048 (28.8%) @9.5x, remaining 4:14 RBU 100.0% UBU 100.0%
  875659264/2886402048 (30.3%) @9.7x, remaining 4:05 RBU  99.8% UBU 100.0%
  920715264/2886402048 (31.9%) @9.8x, remaining 3:54 RBU 100.0% UBU 100.0%
  966361088/2886402048 (33.5%) @9.9x, remaining 3:44 RBU 100.0% UBU 100.0%
1012531200/2886402048 (35.1%) @10.0x, remaining 3:36 RBU 100.0% UBU 100.0%
1059225600/2886402048 (36.7%) @10.1x, remaining 3:27 RBU 100.0% UBU 100.0%
1106444288/2886402048 (38.3%) @10.2x, remaining 3:17 RBU 100.0% UBU 100.0%
1150877696/2886402048 (39.9%) @9.6x, remaining 3:11 RBU 100.0% UBU 100.0%
1197539328/2886402048 (41.5%) @10.1x, remaining 3:03 RBU 100.0% UBU 100.0%
1246363648/2886402048 (43.2%) @10.6x, remaining 2:55 RBU  99.8% UBU 100.0%
1295712256/2886402048 (44.9%) @10.7x, remaining 2:48 RBU 100.0% UBU 100.0%
1345585152/2886402048 (46.6%) @10.8x, remaining 2:40 RBU 100.0% UBU 100.0%
1396015104/2886402048 (48.4%) @10.9x, remaining 2:32 RBU  99.8% UBU 100.0%
1446969344/2886402048 (50.1%) @11.0x, remaining 2:26 RBU 100.0% UBU 100.0%
1498447872/2886402048 (51.9%) @11.2x, remaining 2:18 RBU 100.0% UBU 100.0%
1550516224/2886402048 (53.7%) @11.3x, remaining 2:11 RBU 100.0% UBU 100.0%
1603108864/2886402048 (55.5%) @11.4x, remaining 2:05 RBU 100.0% UBU 100.0%
1656258560/2886402048 (57.4%) @11.5x, remaining 1:58 RBU 100.0% UBU 100.0%
1709932544/2886402048 (59.2%) @11.6x, remaining 1:52 RBU 100.0% UBU 100.0%
1764196352/2886402048 (61.1%) @11.7x, remaining 1:46 RBU 100.0% UBU 100.0%
1818951680/2886402048 (63.0%) @11.9x, remaining 1:39 RBU 100.0% UBU 100.0%
1874231296/2886402048 (64.9%) @12.0x, remaining 1:33 RBU 100.0% UBU 100.0%
1930100736/2886402048 (66.9%) @12.1x, remaining 1:27 RBU 100.0% UBU 100.0%
1986461696/2886402048 (68.8%) @12.2x, remaining 1:21 RBU 100.0% UBU 100.0%
2043412480/2886402048 (70.8%) @12.3x, remaining 1:15 RBU  99.8% UBU 100.0%
2094792704/2886402048 (72.6%) @11.1x, remaining 1:10 RBU 100.0% UBU 100.0%
2152726528/2886402048 (74.6%) @12.5x, remaining 1:04 RBU 100.0% UBU 100.0%
2211217408/2886402048 (76.6%) @12.7x, remaining 0:59 RBU 100.0% UBU  97.1%
2270265344/2886402048 (78.7%) @12.8x, remaining 0:53 RBU  99.8% UBU 100.0%
2329804800/2886402048 (80.7%) @12.9x, remaining 0:47 RBU 100.0% UBU 100.0%
2389901312/2886402048 (82.8%) @13.0x, remaining 0:42 RBU 100.0% UBU 100.0%
2450554880/2886402048 (84.9%) @13.1x, remaining 0:36 RBU 100.0% UBU  97.1%
2511732736/2886402048 (87.0%) @13.2x, remaining 0:31 RBU 100.0% UBU  97.1%
2573467648/2886402048 (89.2%) @13.4x, remaining 0:26 RBU 100.0% UBU  97.1%
2635726848/2886402048 (91.3%) @13.5x, remaining 0:20 RBU 100.0% UBU  97.1%
2698543104/2886402048 (93.5%) @13.6x, remaining 0:15 RBU 100.0% UBU  97.1%
2761883648/2886402048 (95.7%) @13.7x, remaining 0:10 RBU 100.0% UBU  97.1%
2825781248/2886402048 (97.9%) @13.8x, remaining 0:04 RBU 100.0% UBU  97.1%
builtin_dd: 1409376*2KB out @ average 9.1x1352KBps
/dev/cdrom: flushing cache
/dev/cdrom: closing track
/dev/cdrom: closing disc
/dev/cdrom: reloading tray

To verify the disc…

$ dvd+rw-mediainfo /dev/cdrom
INQUIRY:                [hp      ][DVD-RAM GHA3N   ][RH07]
Mounted Media:         1Bh, DVD+R
Media ID:              CMC MAG/M01
Current Write Speed:   16.0×1385=22160KB/s
Write Speed #0:        16.0×1385=22160KB/s
Write Speed #1:        8.0×1385=11080KB/s
Write Speed #2:        6.0×1385=8310KB/s
Speed Descriptor#0:    02/1409375 R@13.2×1385=18280KB/s W@16.0×1385=22160KB/s
Speed Descriptor#1:    02/1409375 R@13.2×1385=18280KB/s W@8.0×1385=11080KB/s
Speed Descriptor#2:    02/1409375 R@13.2×1385=18280KB/s W@6.0×1385=8310KB/s
Media Book Type:       00h, DVD-ROM book [revision 0]
Legacy lead-out at:    1409376*2KB=2886402048
Disc status:           complete
Number of Sessions:    1
State of Last Session: complete
Number of Tracks:      1
Track State:           partial/complete
Track Start Address:   0*2KB
Free Blocks:           0*2KB
Track Size:            1409376*2KB
Track#1  :             14@0
Track#AA :             14@1409376
Multi-session Info:    #1@0
READ CAPACITY:          1409376*2048=2886402048

Note “Disc status: complete” and “State of Last Session: complete”.

Mission accomplished! Also, don’t forget to run “yum remove brasero“.

Working with data discs

To create an appendable data disc, for the first time use the below command, which has flags for the Rock-Ridge / Joilet extensions (CD/DVD standards):

# growisofs -Z /dev/cdrom -R -J /data_files

Then, to append more data to the disc:

# growisofs -M /dev/cdrom -R -J /data_files2

And of course when you’re finished and need to give the disc to your coworker:

# eject /dev/sr0

I will have to try this in the future.


Applied FreeBSD: Enabling the Serial Console

To enable the serial console in FreeBSD, edit /boot/loader.conf and add the following:


The above configuration allows for the use of both a video console connected to some form of a display port and the serial port.  It also sets the console baud rate to 115,200 baud rather than the default 9,600 baud. The default for the console is 8N1 9600 baud, just for reference.

Also, edit /boot.config (it may need to be created) and add the following:


According to the man page for boot.config(5), this activates the serial console during the boot process. Finally, to get a serial console login from the host on the other end of the serial cable, in this case, a RHEL7 box, use screen:

sudo screen /dev/ttyS0 115200

I have my FreeBSD box attached to my Linux workstation via a serial patch cable. Of course I can use ssh to remotely login and manage the FreeBSD box, but in case my little network goes down, I can still login to my FreeBSD box.

Revisiting Windows IoT

I was cleaning up my workspace this morning and my Raspberry Pi 3 device caught my eye. I haven’t messed with Windows IoT since the summer when I gave up due to the immaturity of the platform. I decided to check to check up on the state of things–after all, I still have a project in mind. It looks like Microsoft finally made an official release for Windows IoT: Windows 10 Build 10.0.14393.693. I downloaded the image and thought I would give this platform another shot.

Once again I could not get the Raspberry Pi 3 to boot. I had issues with the Raspberry Pi 2 as well. So next I reformatted the SD card, and tried again. No luck with the Raspberry Pi 3. However, the Raspberry Pi 2 was able to come up, and I could ssh into the device as well as control it through IoT Dashboard. I tried again and again with the Raspberry Pi 3 for quite awhile, and just when I was ready to give up, I noticed the LEDs. After applying power, there is some flashing green (ACTIVE) LEDs. After a few seconds though, there was no more green (ACTIVE) LEDs flashing, but the red power LED flashed once every couple of seconds. The Raspberry Pi documentation is not very easy to navigate for technical details, but after some searching it appears that the this happens when the power supply dips too far below 5.0 V.

I tried a few different wall-wart adapters from various phones or adapters, but no luck. Instead of using a wall-wart power supply, I decided to use the USB 3.0 port on the front of my PC as the power supply. And sure enough, within a few seconds, I was able to see the Raspberry Pi 3 in the IoT dashboard. It’s alive~~~~!

With the device working, now it was time to tackle Visual Studio. I probably should not have done so, but I am in the midst of upgrading to Visual Studio 2017. The upgrade is not going well either. I installed, rebooted the system as was requested at the end of the install, then tried to start Visual Studio 2017, but I have had a screen for hours now saying “We’re getting things ready…thanks for your patience.” I am going to have to kill the process and try again. Nothing ever upgrades smoothly in Windows land.

To be determined….as usual. I have read good things about C++ enhancements in Visual Studio 2017. I hope things are better in the Windows IoT world too.

Applied FreeBSD: Basic iSCSI

iSCSI is often touted as a low-cost replacement for fibre-channel (FC) Storage Area Networks (SANs). Instead of having to setup a separate fibre-channel network for the SAN, or invest in the infrastructure to run Fibre-Channel over Ethernet (FCoE), iSCSI runs on top of standard TCP/IP. This means that the same network equipment used for routing user data on a network could be utilized for the storage as well. In practice, to get high-levels of performance, it is advised that system designers consider iSCSI Host Bus Adaptors (HBAs) for each iSCSI participating team, and that the network at a minimum have a separate VLAN for iSCSI traffic–or more ideally, have separate physical network.

My disclaimer: this article does not cover any of the above performance enhancements! The systems in this article are setup and configured in a VMWare Workstation virtualized environment so that I don’t have to physically procure all of the hardware just to learn about iSCSI.

This article will cover a very basic setup where a FreeBSD server is configured as an iSCSI Target, and another FreeBSD server is configured as the iSCSI Initiator. The iSCSI Target will export a single disk drive, and the initiator will create a filesystem on this disk and mount it locally. Advanced topics, such as multipath, ZFS storage pools, failover controllers, etc. are not covered.  Please refer to the following documentation on iSCSI for more information:

Now to get started…

iSCSI Target Test Setup

The disk drive which should be shared on the network is /dev/ada0, a 5G SATA disk created in VMWare that I attached to the system before starting it up. With FeeBSD, iSCSI is controled by the ctld daemon, so this needs to be enabled on the system. While at it, why not go ahead and enable it at boot time too?

root@bsdtarget:~ # echo ‘ctld_enable=”YES”‘ >> /etc/rc.conf
root@bsdtarget:~ # service start ctld
Starting iscsid.

The real magic is the /etc/ctl.conf file, which contains all of the information necessary for ctld to share disk drives on the network. Check out the man page for /etc/ctl.conf for more details; below is the configuration file that I created for this test setup. Note that on a system that has never had iSCSI configured, there will be no existing configuration file, so go ahead and create it.

root@bsdtarget:/dev # less /etc/ctl.conf
auth-group test{
chap “iscsitest” “bsdforthewin”

portal-group pg0 {
discovery-auth-group no-authentication

target iqn.2017-02.lab.testing:basictarget {
auth-group no-authentication
portal-group pg0
lun 0 {
path /dev/ada0
size 5G
lun 1 {
path /dev/ada1
size 5G

For this setup, LUN 0 will be used by a FreeBSD iSCSI Initiator. I have LUN 1 configured for experimenting with Windows Server at a later time. Before starting ctld, it is a good idea to make sure that the /etc/ctl.conf file is not readable by all users (ctld will complain). At a later point it might be necessary to add iSCSI authentication for the sessions, and it would not be wise to have all users able to look at the authentication secret password.

root@bsdtarget:~ # chmod 640 /etc/ctl.conf
root@bsdtarget:~ # service start ctld

If there are any syntax errors or warnings, ctld will complain about it on the console. The ctladm tool can be used to query the system for more information, for example:

root@bsdtarget:/dev # ctladm lunlist
(7:0:0/0): <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-4 SCSI device
(7:0:1/1): <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-4 SCSI device
root@bsdtarget:/dev # ctladm devlist
LUN Backend Size (Blocks) BS Serial Number Device ID
0 block 10485760 512 MYSERIAL 0 MYDEVID 0
1 block 10485760 512 MYSERIAL 1 MYDEVID 1


That’s really it for the iSCSI Target configuration. The real effort is in setting up the /etc/ctl.conf file. And for a real production system, there would be more configuration with the exported disks, such as using ZFS shares, RAID-1 mirroring, et cetera.

iSCSI Initiator Test Setup

In order for a FreeBSD host to become an iSCSI Initiator, the iscsd daemon needs to be started. It doesn’t hurt to go ahead and add the instruction to /etc/rc.conf so that iscsid is started when the system comes up.

root@bsdinitiator:~ # echo ‘iscsid_enable=”YES”‘ >> /etc/rc.conf
root@bsdinitiator:~ # service start iscsid
Starting iscsid.

Next, the iSCSI Initiator can manually connect to the iSCSI target using the iscsictl tool. While setting up a new iSCSI session, this is probably the best option. Once you are sure the configuration is correct, add the configuration to the /etc/iscsi.conf file (see man page for this file). For iscsictl, pass the IP address of the target as well as the iSCSI IQN for the session:

root@bsdinitiator:~ # iscsictl -A -p -t iqn.2017-02.lab.testing:basictarget

The command returns silently, but a look at /var/message/logs shows that the remote disk was recognized and is now recognized by the Initiator as /dev/da1.

da1 at iscsi3 bus 0 scbus34 target 0 lun 0
da1: <FREEBSD CTLDISK 0001> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number MYSERIAL 0
da1: 150.000MB/s transfers
da1: Command Queueing enabled
da1: 5120MB (10485760 512 byte sectors)

The iSCSI session connection status can also be verified with iscsictl:

root@bsdinitiator:~ # iscsictl -L
Target name                                                 Target portal          State
iqn.2017-02.lab.testing:basictarget       Connected: da1

Once the disk is recognized by the iSCSI Initiator system, it can be configured for use on the Initiator like a regular SCSI/SATA disk attached to the system physically. The commands below create a partition and UFS filesystem on /dev/da1.

root@bsdinitiator:~ # gpart create -s gpt /dev/da1
root@bsdinitiator:~ # gpart add -t freebsd-ufs -l 1m /dev/da1
root@bsdinitiator:~ # newfs -U /dev/da1p1
/dev/da1p1: 5120.0MB (10485688 sectors) block size 32768, fragment size 4096
using 9 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
with soft updates
super-block backups (for fsck_ffs -b #) at:
192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112
root@bsdinitiator:~ # mkdir /iscsi_share
root@bsdinitiator:~ # mount -t ufs -o rw /dev/da1p1 /iscsi_share

If there is already a filesystem resident on the device, it only needs to be mounted after the iSCSI session is connected. Back on the iSCSI Target machine, it is possible to see all of the iSCSI Initiators connected

root@bsdtarget:/dev # ctladm islist
ID   Portal                   Initiator name                                                 Target name
6   iqn.1994-09.org.freebsd:bsdinitiator      iqn.2017-02.lab.testing:basictarget

Finally, if for some reason it is necessary to disconnect the system, unmount the filesystem and use iscsictl to disconnect the iSCSI session.

root@bsdinitiator:~ # umount /iscsi_share
root@bsdinitiator:~ # iscsictl -R -t iqn.2017-02.lab.testing:basictarget

There is much more to explore with iSCSI, this is just the very beginning, but it serves a a model and a starting point for this work. More to come in the future!

Update: Windows iSCSI Initiator

I am not a very savvy Windows user, and I am very new to Windows Server. I have just started to learn some of the basics. As such, I thought I’d try setting up a Windows Server 2016 host as an iSCSI Initiator. I won’t go into much detail other than what is required for setting up the iSCSI parts. Go ahead and fire up Server Manager.


From the “Tools” menu, select iSCSI Initiator. It is also possible to start this application from the Windows search tool by searching for “iSCSI Initiator”. As shown below, when running it for the first time, Microsoft’s iSCSI service may not be running. If not, start it up!initiator2

There are many options for configuring the iSCSI Initiator, but for demonstration purposes we’ll cover the basic case. In the Target box, enter the IP address of the iSCSI Target machine and click on the Quick Connect button.


A screen should pop-up window finding the IQN for the iSCSI Target service, and it should also state somewhere that the Login was successful.


After closing out the pop-up window, the target should now be in the Discovered targets area of the Targets tab.


Next go to the Volumes and Devices tab. Unless you know the exact mount point for the iSCSI volume, the best bet is to click the Auto Configure button which will get the data from the iSCSI Target, as shown below.


I bet you wouldn’t have memorized that!  Both LUN 0 and LUN 1 are recognized by Windows. Press OK to exit out of the iSCSI Initiator application. Next, open up the Disk Management application on the Windows Server.


Notice that two new 5 GB disks are present. The tricky part here is that I am not sure which is LUN 0 and which is LUN 1. My best guess is that the disk that is recognized as a healthy primary partition is LUN 0 which contains a GPT label and is UFS formatted.  Thus the unrecognized disk must be LUN 1, which was not modified by the FreeBSD iSCSI Initiator. In reality I would deploy two iSCSI portal groups, one for the FreeBSD iSCSI Initiators and one for Windows iSCSI Initiators. I might have a third portal group for shared volumes.

For the unrecognized volume, create a MBR partition with the Disk Management tool, and then create a FAT32 partition on this disk as well. I decided to name the partition ISCSI_BSD. As shown below, on this Windows Server, the E: drive is now LUN 1, or /dev/ada2 back on my FreeBSD iSCSI Target machine.


The iSCSI drive shows up as a regular drive in Windows Explorer, as shown below.


Inside I created a special message for viewing from the FreeBSD side:


Finally, it is possible to verify the Windows access using the FreeBSD iSCSI Initiator. Reload the iSCSI Target session data, and now /dev/da2 is available on the FreeBSD Initiator. Even nicer, the FAT32 partitions are recognized by FreeBSD–less work to do! On Windows Server an MBR partition was created, which shows up as /dev/da2p1 in FreeBSD, and the actual FAT32 data partition is /dev/da2p2.

root@bsdinitiator:/iscsi_win_edrive # iscsictl -R -t iqn.2017-02.lab.testing:basictarget
root@bsdinitiator:/iscsi_win_edrive # iscsictl -A -p -t iqn.2017-02.lab.testing:basictarget

root@bsdinitiator:~ # ls -l /dev/da2*
crw-r—– 1 root operator 0x72 Mar 4 22:32 /dev/da2
crw-r—– 1 root operator 0x77 Mar 4 22:32 /dev/da2p1
crw-r—– 1 root operator 0x78 Mar 4 22:32 /dev/da2p2
root@bsdinitiator:~ # mount_msdosfs /dev/da2p2 /iscsi_win_edrive
root@bsdinitiator:~ # cd /iscsi_win_edrive/
root@bsdinitiator:/iscsi_win_edrive # ls
$RECYCLE.BIN hello.txt
System Volume Information
root@bsdinitiator:/iscsi_win_edrive # cat hello.txt
Hello FreeBSD! This is Windows Server!
I made your /dev/ada1 into a FAT32 partition.
I call it E: Drive. Thank you!

It works! I can see the message from Windows land.