Using jumbo frames with Fujitsu gigabit Ethernet adaptors

While performing some testing a few weeks back, I needed to enable jumbo frames on one of our Fujitsu 250s. This was accomplished with the following three steps:

1. Add the following line to /etc/system:
$ echo “set fjgi:fjgi_jumbo=1” >> /etc/system

2. If the default 9000 byte MTU isn’t ideal, add the preferred MTU to the /etc/fjmtu.fjgiX file
$ echo “8192” >> /etc/fjmtu.fjgi0

3. Reboot the system.

If everything works correctly, ifconfig will report the larger mtu.

Measuring DNS latency with nsping

While debugging a DNS problem a few weeks back, I needed a way to measure the time it took a name server to respond to a DNS request. After poking around the OpenBSD ports collection, I came across the nsping utility. Nsping queries a DNS server passed on the command line, and reports the time it took the server to resolve a name. The following example shows how to use nsping to measure the time it takes to resolve the name on the name server

$ nsping -t 5 -h

NSPING ( Hostname = "", Type = "IN A"
+ [   0 ]    46 bytes from   76.224 ms [    0.000 san-avg ]
+ [   1 ]    46 bytes from   79.862 ms [   78.043 san-avg ]
+ [   3 ]    46 bytes from   79.902 ms [   78.663 san-avg ]
+ [   4 ]    46 bytes from   79.912 ms [   78.975 san-avg ]
+ [   6 ]    46 bytes from   79.920 ms [   79.164 san-avg ]
Total Sent: [   7 ] Total Received: [   5 ] Missed: [   2 ] Lagged [   0 ]
Ave/Max/Min:   79.164 /   79.920 /   76.224

Each line contains the size of the response, the time it took to complete the request, and a sequence number. The summary line contains the numer of requests that were sent to the server, the number that were missing, and the average, maximum and minimum response times. If you want to use a resource record type other than “A,” (the default resource record type) you can invoke nsping with the “-T” option the resource record type to use:

$ nsping -t 5 -h -T mx

NSPING ( Hostname = "", Type = "IN MX"
+ [   0 ]   136 bytes from   73.875 ms [    0.000 san-avg ]
+ [   1 ]   136 bytes from   79.905 ms [   76.890 san-avg ]
+ [   2 ]   136 bytes from   80.476 ms [   78.085 san-avg ]
+ [   3 ]   136 bytes from   80.030 ms [   78.572 san-avg ]
+ [   6 ]   136 bytes from   80.004 ms [   78.858 san-avg ]
Total Sent: [   7 ] Total Received: [   5 ] Missed: [   2 ] Lagged [   0 ]
Ave/Max/Min:   78.858 /   80.476 /   73.875

Now to figure out why DNS responses are missing!

Solaris device in use checking

One nifty feature that recently made it’s appearance in Solaris 10 is device in use checking. This feature is implemented by the shared library, and allows utiltiies to see if a device is being used, and what it is being used for. This is really neat, and I love the fact that format now prints what each partition on an active device is being used for:

$ format

Searching for disks...done

       0. c0d0 
       1. c1d0 
Specify disk (enter its number): 0
selecting c0d0
Controller working list found
[disk formatted, defect list found]
/dev/dsk/c0d0s0 is part of SVM volume stripe:d10. Please see metaclear(1M).
/dev/dsk/c0d0s1 is part of SVM volume stripe:d30. Please see metaclear(1M).
/dev/dsk/c0d0s3 is part of SVM volume stripe:d20. Please see metaclear(1M).
/dev/dsk/c0d0s4 is part of active ZFS pool home. Please see zpool(1M).
/dev/dsk/c0d0s7 contains an SVM mdb. Please see metadb(1M).

I digs me some Solaris!

Monitoring interface throughput on OpenBSD systems

While persuing the OpenBSD ports collection a few weeks ago, I came across the ifstat utility. This nifty utility allows you to view bandwidth totals for each interface in a server, and at specific intervals. Here is a sample run showing the bandwidth in and out of the sis0 and sis1 Ethernet interfaces, and the total bandwidth in and out of the system:

$ ifstat -TAb 5

       sis0                sis1               Total       
 Kbps in  Kbps out   Kbps in  Kbps out   Kbps in  Kbps out
  129.96      4.37      3.91    131.71    133.87    136.09
  130.48      5.43      4.77    131.98    135.25    137.41
  132.21      4.24      3.60    133.71    135.81    137.95

This is a nifty utility, and one I plan to add to my stock OpenBSD builds!

Sometimes it’s the little things that bite you

After installing a new OpenBSD image on my Soekris net4801, I needed to become root to perform some post installation configuration. When I ran the su command, it exited without switching me to the root user:

$ su

This baffled me for a minute, since my user and group identifiers looked fine, and I was in the wheel group (OpenBSD allows you to use the group wheel to control which users can become uid 0):

$ id
uid=1000(matty) gid=1000(matty) groups=1000(matty), 0(wheel)

To see what was going on, I ran ktrace to view the call path for the su executable:

$ ktrace su

After reviewing the complete dump, I noticed that the su executable couldn’t open the secure passwd database:

$ kdump | egrep ‘(NAM|open)’

 < ..... >
 28302 su       NAMI  "/etc/spwd.db"
 28302 su       RET   open -1 errno 13 Permission denied
 < ..... >

It then dawned on me that I shouldn’t be able to ktrace a setuid executable as an unprivileged user, so I decided to check the permissions of the su utility to see why the kdump worked:

$ ls -la /usr/bin/su
-r-xr-xr-x 1 root wheel 14948 Mar 2 2006 /usr/bin/su

Well I’ll be. When I extracted the files tonight to create my archive, I either extracted then as an unprivileged user (which is why the setuid / setgid bits weren’t preserved), or I forgot to use tar’s “-p” option to preserve the file modes (I no longer have the history file, so I can’t see where I made my mistake). I think the tryptophan from the turkey is setting in. :)

Locating OpenBSD devices for kernel builds

I run OpenBSD on a few soekris net4801s, which don’t have a whole lot of memory. To ensure that I am efficiently using the hardware, I build custom kernels that contain just the devices needed to load and run the OpenBSD kernel on the soekris. This minizes the kernel memory footprint, and allows me to eeek out a few extra pages of spare memory. To build a custom kernel with just the devices I need, I usually start by running the dmassage utility to identify the devices on my system:

$ dmassage -t

    |  \-pcibios0
       |  \-audio0
       |  \-isa0
       |     |-fdc0
       |     |  \-fd0
       |     |-isadma0
       |     |-npx0
       |     |-pckbc0
       |     |  |-pckbd0
       |     |  |  \-wskbd0
       |     |  \-pmsi0
       |     |     \-wsmouse0
       |     \-pcppi0
       |        |-midi0
       |        \-spkr0
       |  |-atapiscsi0
       |  |  \-scsibus0
       |  |     \-cd0
       |  \-wd0
       |  \-usb0
       |     \-uhub0

Once I have the devices, I use my OpenBSD kernel build procedure, but trim the devices that aren’t displayed by dmassage. This works pretty well, and allows me to maximize the hardware in my Soekris.