MR HIDDEN . COM

NSTX (IP-over-DNS) HOWTO
Problem
You’re sitting in an airport or in a cafe, and people want your money for Internet access. They do allow DNS traffic, though.

If the ISP allows DNS traffic to any DNS server (and not just their own), you might consider running OpenVPN on UDP port 53 (thanks to Norman Rasmussen for this suggestion). If they don’t, however, NSTX comes to the rescue. NSTX is a hack to tunnel IP traffic over DNS. NSTX (IP-over-DNS) seems cool, but you cannot get it to work. You’ve downloaded the latest version, maybe because you saw it mentioned on Slashdot. You’ve looked at the nstx project page and the freshmeat page. You even tried reading some confusing documentation. Maybe you gave up and tried OzymanDNS. But curiousity got the better of you. You really want to use this.

Once you’ve followed these instructions, you basically have a remote proxy, providing you with access to the Internet. Communication between you and the remote proxy is over NSTX.

If DNS traffic does not work, but ICMP traffic (i.e., ping) works, try ICMPTX: IP-over-ICMP. Note that these instructions play nicely with ICMPTX. You can run both on one proxy.
Keywords
nstx, ip-over-DNS, tunnel, firewall piercing, ifconfig, route, tun/tap, tun0.
Solution

You need several things to get going:

* a DNS server that you can configure, (we’ll call this ns.example.com)
* another server, one not running DNS. We’re going to assume the IP address of this machine is 1.2.3.4. The reason you cannot run DNS on the same machine, is that you’re going to run nstx on this machine. Nstx must run on port 53, like DNS.
* a crippled Internet connection, i.e., one that only allows you to issue DNS queries.

Configure a new DNS subdomain
Let’s assume you’re running the domain “example.com”. The nameserver for this domain is, as mentioned before, “ns.example.com”. Configure “ns.example.com” by adding a subdomain, “tunnel.example.com”. You do this by appending the following DNS records at the end of the zone file for “example.com”:

;
; subdomain for IP-over-DNS tunnelling
;
$ORIGIN tunnel.example.com.
@ IN NS ns.tunnel.example.com.
ns IN A 1.2.3.4

In other words. We configured 1.2.3.4 to be the name server for a new subdomain “tunnel.example.com”.
Install and configure the bogus DNS server
On the machine 1.2.3.4, make sure your kernel supports the TUN/TAP network device. If you installed a standard 2.6 kernel image, it does. You may have to manually /sbin/modprobe tun. Install the nstx Debian package:

# apt-get install nstx

Edit /etc/default/nstx and set NSTX_DOMAIN to “tunnel.example.com” and set start_nstxd to “yes”. Finally, set ifup_tun0 to “yes”. In /etc/network/interfaces, define a new interface tun0, as follows:

iface tun0 inet static
address 10.0.0.1
netmask 255.0.0.0

Now start the server by running:

# /etc/init.d/nstxd restart

If you’re not running Debian, you can skip all that and just download the code, compile it manually, and start the server by hand and then configure the tun0 network device:

# nstxd tunnel.example.com
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.1 netmask 255.255.255.0

Whether you’re running Debian or not, after running the nstx server, make sure you now have a tun0 device:

# /sbin/ifconfig tun0
tun0 Link encap:UNSPEC HWaddr XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX
inet addr:10.0.0.1 P-t-P:10.0.0.1 Mask:255.0.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:50 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Now you need to enable forwarding on this server. I use iptables to implement masquerading. There are many HOWTOs about this (a simple one, for example). On Debian, the configuration file for iptables is in /var/lib/iptables/active. The relevant bit is:

*nat
:PREROUTING ACCEPT [6:1596]
:POSTROUTING ACCEPT [1:76]
:OUTPUT ACCEPT [1:76]

-A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
COMMIT

Restart iptables:

/etc/init.d/iptables restart

and enable forwarding:

echo 1 > /proc/sys/net/ipv4/ip_forward

You can make sure this is permanent by editing /etc/sysctl.conf:

net/ipv4/ip_forward=1

Configure the client

Make sure the kernel on the client machine also supports the TUN/TAP network device. If you installed a standard 2.6 kernel image, it does. You may have to manually /sbin/modprobe tun. Install the nstx Debian package:

# apt-get install nstx

Edit /etc/default/nstx and set NSTX_DOMAIN to “tunnel.example.com” and set start_nstxcd to “yes”. Finally, set ifup_tun0 to “yes”. In /etc/network/interfaces, define a new interface tun0, as follows:

iface tun0 inet static
address 10.0.0.2
netmask 255.0.0.0
mtu 500 # optional, may solve ssh problems

Marc Merlin points out that you may you want to add something like (below the mtu line)

post-up route del default; route add -net default gw 10.0.0.1

Many thanks to Marc, also for pointing out the mtu option to solve potential ssh issues.

Alright, now you’re sitting at an airport or in a cafe, and you have internet access and they want your money before allowing you on the Internet. However, you noticed that you can issue DNS queries.

Assuming you got an IP address through DHCP, you should now know the IP address of the DNS server they want you to use. Your /etc/resolv.conf will contain at least one “nameserver” entry. Make sure you use the first nameserver entry in /etc/resolv.conf and remove the others. For the sake of this example, let’s call the first and remaining nameserver 66.77.88.99. Edit /etc/default/nstx and change set NSTX_DNS_SERVER to “66.77.88.99″. The latest nstx Debian package obviates this manual step as follows:

NSTX_DNS_SERVER=`grep nameserver /etc/resolv.conf |head -1|awk ‘{print $2}’`

That is, it simply sets NSTX_DNS_SERVER to the IP address of the first nameserver entry in /etc/resolv.conf.

Now, (re)start the nstx client:

# /etc/init.d/nstxcd restart

If you don’t have Debian, start the client manually:

# nstxcd tunnel.example.com 66.77.88.99
# /sbin/modprobe tun
# /sbin/ifconfig tun0 up 10.0.0.2 netmask 255.255.255.0

Make sure you now have a tun0 device:

# /sbin/ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.2 P-t-P:10.0.0.2 Mask:255.0.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

By running /sbin/route -n, figure out what your gateway is. It’s the record with the “UG” Flags field. For example:

# /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

OK. So “192.168.1.1″ is our gateway. Assuming your wireless network device is called “wlan0″ (but it might well be “eth1″, or whatever), run:

# /sbin/route del default
# /sbin/route add -host 66.77.88.99 gw 192.168.1.1 dev wlan0
# /sbin/route add default gw 10.0.0.1 tun0

Notice that “192.168.1.1″ is the IP address of the gateway we learned by running “/sbin/route -n”. Similarly, “66.77.88.99″ is the nameserver from /etc/resolv.conf. Make sure you plug in the correct IP address in both cases.

You should now be all set. All DNS traffic is going straight to 66.77.88.99. All other traffic will be tunnelled through 1.2.3.4, via DNS.
URL: http://thomer.com/howtos/nstx.html
Copyright © 1994-2009 by Thomer M. Gil
Updated: 2007/11/13

Recreating the Dell Utility Partition

(Note: Booting the Dell Utility partition requires a recent Dell bios that includes a bios boot menu with that capability. If your bios does not have that capability, stop here, since there is little point in creating a Dell Utility partition on your computer. You can, of course, create a multiboot system with your own custom utility partition, but that’s a different matter that doesn’t use Dell’s bios boot menu.)

You may wish to recreate the DE partition if the hard disk is upgraded or replaced. For the record, installing delldiag on the hard disk is optional. It’s the same program you can run from the Dell Resource CD (if one came with your computer, and if you can still find it). Many people are satisfied to just run the diagnostic utility from CD when necessary, but the following steps explain how to recreate the DE partition on the hard disk if you choose to do so.

Unfortunately, Dell provides no easy way to restore or recreate the Utility partition. A good commercial partition imaging program (DriveImage, Ghost, BootIt-NG, TrueImage, et al) should have no trouble duplicating the DE partition from the old disk onto the new disk, so should be considered as a first resort. However, you may need to recreate the partition from scratch if the old DE partition was erased, the old disk is not readable or not available, or if you wish to upgrade to a newer version of delldiag, the Dell diagnostic program.

Here’s how to recreate the unsealed version of the DE partition from scratch.

(Note to reader: a certain familiarity with DOS is expected here. Please don’t ask me for help about basic DOS matters. The following is one way of doing things, but feel free to use your own methods to do the same things below.)

1. Make sure you have unallocated disk space in which to create the partition. This is not a problem on a new disk, but if the disk has existing partitions, you may need use something like PartitionMagic or Ranish Partition Manager to free up some disk space. A typical utility partition is about 30-60 MB.
   (Note to reader: although it doesn’t appear to be strictly necessary, for compatibility I recommend locating the utility partition at the front of the disk.)
2. Make a Primary FAT16 partition. PartitionMagic (retail) and Ranish Partition Manager (freeware) are popular tools for this, or boot to a DOS floppy and use fdisk.If you are using fdisk, the choice is called a “Primary DOS” partition, and you will also need to perform a second step to separately format the partition. Reboot again and use the “format c:” command, which should default to FAT16 on a 30-60 MB partition.

   If you are using PartitionMagic, the FAT16 choice is simply called “FAT”, and the utility formats the partition at the same time it is created.

3. Make the partition ‘active’ so it will show up as “drive C:” in the following steps.
4. Reboot so the changes are recognized.
5. Make the partition bootable. Boot from a DOS floppy, then “sys c:” to transfer the system files.
6. Copy the Dell Diagnostic program. The program (delldiag.exe) and its support files will be together in the same directory. Find these on the Resource CD or Utility CD and copy everything in that directory to C:.Or, download the delldiag program for your model from the Dell website, extract all files, and put them all in C:. If you have a choice, download the CDD*.EXE or CZ*.EXE version because it’s easier to extract the files from those packages than from the CD*.EXE version. If you download an ‘update’ version of delldiag, you’ll need to open the .EXE file with a zip program (such as PKZip or WinZip) and manually extract the files from the package.

   Note: the diagnostic program doesn’t include config.sys, autoexec.bat, or dellboot.exe, so…

7. Add a reboot program. Dell uses one called dellboot.exe, but any old reboot program will do. There are plenty on the web, such as reboot.com, reset.com, warmboot.com, et al–grab one and put it in C:.
8. Create config.sys and autoexec.bat files. These are ordinary text files that run when the partition is booted, so use them to automatically launch delldiag.exe and then reboot at the end. Hopefully you know enough DOS to know how to do this. Here are the contents of the config.sys and autoexec.bat files Dell uses.
   
9. Change the partition-type byte to DEh. Boot to DOS, load a mouse driver, and run ptedit (which you can get here). From Step 3, the partition type should be ‘06′. Change it to ‘DE’.(Note to reader: ptedit is tough to use without a mouse, so make sure you load a DOS mouse driver before launching ptedit.)
10. Make Windows the active partition. The active partition is the one marked 80h in the boot column of the partition table. If Windows isn’t installed yet, install it now. (It will probably make itself the active partition in the process.) If Windows is already installed, use ptedit to change the Windows partition from Boot-type ‘00′ to ‘80′. Remember that only one partition should be marked ‘80′.

With Windows as the active partition, it will be the one that boots normally. The DE partition will only boot when selected from the bios boot menu.

This recreates the unsealed version of the DE partition, not the sealed version. (But why would anyone have a need to recreate the sealed version?)

Warning: If your computer is equipped with a Dell PC-Restore partition, that function expects to find the config.bts file in the DE partition so that it can return the computer to a sealed state following a restore of the operating system. You will either need to recreate that file, or edit the PC-Restore partition’s autoexec.bat file so it skips returning the system to the sealed state.

Backup the box onto a different machine…

Then you can restore from a miniroot if things go wrong…

Recommended CDROM Units

Many people say Toshiba and Plextor are the brands to go for. However, I’ve had problems with the 40X Toshiba SCSI CDROM, and I saw some odd effects with the 40X Plextor. I strongly suspect that, in both cases, a firmware update (normally done with a PC) would fix these issues; however, if you’re looking for a newer SCSI CDROM which will definitely work ok with no problems, then I recommend the 32X TEAC 532S CDROM. This is a very good model, works with anything, and I’ve never had any problems with it. More recently, I’ve also found the NEC 40X 3010A works just fine too; plus, the NEC is often available with a black front plate - ideal for installation in an Indigo2 or Origin system where the owner cares about aesthetic appearance.

If you’re having problems with a CDROM, make sure the block size is 512, parity is ON, and check to see if termination may be an issue. Also make sure the SCSI ID is set correctly. Company web sites usually have detailed information on older models, or if not then a Google search will usually find the required information.

Note that some older SGI systems may not like CDROMs as recent as a 32X however, no matter what brand it is. I’m thinking here of Personal IRIS, POWER Series, IRIS Indigo, etc., whereas a system such as Indy/Indigo2 or later will be able to use newer CDROMs just fine. It’s less of a problem when a system has already been installed and is ready to use; the problems tends to occur when doing an initial installation from the OS CDs. In particular, I’ve found that IRIS Indigo often doesn’t like newer CDROMs when doing an OS install, especially the earlier R3000 Indigo. The problem is probably due to the PROM which can’t deal with a newer CDROM correctly. I had to use an old 4X to do the initial install, but afterwards a 32X TEAC worked ok when the system was running (because it’s then the OS, not the PROM, which is dealing with CDROM access).

Thus, with respect to early systems, especially for doing OS installations, it may be wise to locate an older 1X, 2X or 4X CDROM just in case the use of an older model is essential, but have a newer speedy model for all other uses.

Older CDROMs may be caddy-types, but both caddy and non-caddy models are not hard to find (I always have some available, including external units). The most common are Toshiba 2X or 4X units (the brand favoured by SGI for many years), typically the XM5401B or similar, but I come across NEC, Sony, etc. My personal favourite older CDROM is the Toshiba XM-4101B (not a caddy CDROM), typically dated around 1994. This model is not found so often on the 2nd-hand market, but it has one excellent feature which makes it well worth acquiring if possible, especially for Indigo2 owners: the central cylinder of the CD tray, on which the CDROM sits, holds the CD so securely that it’s possible to use the CDROM vertically, or even upside down! The CD is held rigid because the central cylinder is slightly splayed outwards at the top, locking the CD in place much like some CD jewel cases do. Thus, for Indigo2 owners who have their system on foot stands, or anyone with a system which may have vertically aligned CDROM bay (eg. older high-end systems), this unit is a good choice, though obviously it’s not very fast.

When considering a CDROM, it’s best to stick with the more well-known brands, ie. TEAC, Plextor, Yamaha, NEC, specific Toshibas that are known to work, etc. I would avoid the more obscure makes - the firmware is more likely to be disliked by SGIs.

If you’re looking for a unit specifically for reading CDROMs, then don’t use a CDR or CDRW as a substitute. The firmware of CDRW units is such that, although they may work fine on an SGI for writing CDRs, they can often behave oddly when trying to read CDs; this is probably because CDRW firmware is often too PC-specific. Note that, as with CDROMs, a firmware upgrade (normally done with a PC that is SCSI-capable) may improve the situation; an example of this is given later.

Some CDRWs do work fine for reading CDs (eg. Yamaha 16/10/40 does pretty well), and certain models even work perfectly as a bootable device for OS installations (more on this later), but it’s not worth the risk unless you’re considering a model which is known to work ok. Besides, 2nd-hand CDRW units probably won’t be that fast for reading CDs compared to a normal good CDROM; for example, the CD reading speed of a Yamaha 16/10/40 is definitely not as fast as a TEAC 32X 532S, even though the Yamaha has a theoretically higher speed.
Recommended CDRW Units

I started off doing CD-writing on SGIs with an original external Yamaha 8/4/24 unit (model number CRW8424SX) connected to an R4K/250 Indigo2. It worked very well, with excellent reliability and superb resilience to system load; I found it impossible to harm a CD-write session by doing other things at the same time, often running 100+ apps simultaneously while writing a CD as a perfect demonstration of the reliability and quality of SGIs and the IRIX OS.

I eventually upgraded to an Yamaha 8/8/24 which I came across by chance, selling on the 8/4/24. Note that, as originally shipped, the 8/4/24 was not a bootable device, but before I sold the unit I did a firmware upgrade which made it work just fine as a boot device for SGIs (the update .exe for PCs with SCSI is available on my depot page; the file is called s8410j_e.exe). By contrast, the 8/8/24 was already a bootable device. I suspect this difference may be found across product ranges from other manufacturers too, ie. newer models will probably work better for reading CDROMs than older models, and are more likely to work as a bootable device, although I’ve been told that some manufacturers have ended up breaking their early good firmware support for SGIs, eg. Plextor.

During 2003 I managed to obtain a Yamaha 16/10/40, which works ok as a bootable device too. In general though, if you want something faster than 8X, then similar recommendations apply to CDROMs: stick with the good brands and you should be fine. One caveat with newer models however: at 16X, the Yamaha is pushing data at a rate which is uncomfortably close to the reliable sustained speed of a FastSCSI2 bus in Indigo2. I found that it was no longer possible to do other things at the same time without occasionally harming the CD write session, but note that, unlike PCs, this is NOT due to any OS issue - it’s just a physical limitation of the hardware. However, there is a way to improve the situation slightly, namely turn off any unnecessary service or application which is constantly using the main CPU. The main one I turn off is the local web server:

    /etc/init.d/sgi_apache stop

This makes writing a CD at 16X work just fine on an Indigo2, though it’s still best to leave the system alone. There are four solutions to this:

• Stripe a couple of disks across both the internal and external SCSI channels.
• Access the files to write across a 100Mbit network connection. I’ve not tried this, but it should work ok, but only with a GIO card, ie. a Phobos G160. Obviously, the server supplying the data should be able to supply the data at a speed better than FastSCSI2, so any newer system would do, eg. O2, Octane, Origin200, etc.
• Use some kind of storage option card to allow one to store the data on a faster storage device. The main two possibilities are a GIO64 FibreChannel card (such as the model from Prisa) and a GIO64 USCSI card (such as the Ciprico card). Both of these are certainly rare, but well worth obtaining if possible. I was lucky to obtain a Ciprico card (rated at 40MB/sec) so I had been planning to switch to this, connecting my disks containing the data to the Ciprico card instead of the Indigo2’s supplied external bus. This would allow the 16X Yamaha to function just as the old 8X did and so allow other things to be done at the same time without harming the CD write process.
• Use a different system! eg. O2 or Octane.

Concerning newer CDRW units: as the above shows, at 16X one is approaching the limits of a FastSCSI2 bus in Indigo2. Thus, anything which is beyond 16X will very likely not work well on an old system using FastSCSI2 unless one uses either of the speed increasing methods described above. If absolute speed doesn’t matter to you, then stick with an 8X. If you do need speed, then either increase the bandwidth as suggested above, or use a different system instead such as O2, Octane, Origin, or probably even a ChallengeS (since it’s HVD buses are 20MB/sec, though HVD disks are hard to find). Using a newer system is probably the best solution due to the rareity of FC and USCSI option cards for Indigo2. Indeed, in the end, I upgraded to an R12K/300 Octane MXI which has evolved over time into my current system, an R14K/550 Octane2 V8.
Using CDRW Units

There are two aspects to using CDRW units: creating CD images for writing (or reading a CD to create an image) and writing the image.

The first step is to ensure the correct software is present. Make sure the latest versions of cdrecord, gcombust, mkisofs, etc. are installed. Check freeware.sgi.com and download/install the latest versions.

The main application for creating CD images from files/directories is mkisofs, while the main CD-writing application is cdrecord. If you prefer a GUI interface to these tools, then gcombust provides this option.

All these applications have man pages and/or online help, but there are a vast range of options possible, so what are the basics just to get started? I shall mostly discuss the use of mkisofs and cdrecord here by way of example.

The usual way of writing data to a CDR is to place the required files inside a directory and then use mkisofs to create a raw CD image which consists of the contents of that directory. This image is then written using cdrecord. For these examples, I shall assume the use of an Indigo2 which has an internal 32X CDROM on SCSI controller 0, ID 3 for reading CDs, and an external 8/4/24 CDRW for writing CDRs on SCSI controller 1, ID 4. If you’re using a faster device such as a 16/10/40 on an Octane (which is what I now have) then adjust the speed to 16.

Suppose one has copied/downloaded a number of files and/or directories to a subdirectory in /var/tmp, perhaps like this:

  cd /var/tmp
  mkdir stuff
  cd stuff
  ftp somewhere.org  (and so on)

The most straightforward way to dump this data onto a CDR is as follows:

  cd /var/tmp
  mkisofs -R -o stuff.raw stuff
  cdrecord -v dev=1,4,0 speed=8 stuff.raw

and that’s it! The general procedure is very simple: mkisofs creates the raw image file and then cdrecord writes it to the CDR (or CDRW disc; whichever).

The important aspects to note from the above are:

• The -R option for mkisofs: this generates extra descriptive information about the files in the raw image. One could use ‘-r’ instead which does some extra useful things related to user/group IDs and file access permissions, but I normally use -R as an extra incentive for self-discipline.
• The -o option for mkisofs: the parameter following -o is the name of the image file to create. This doesn’t have to be a file on disk though - it could be a tape device or other unit. Usually though, it’s a disk file name.
• The -v option for cdrecord: this specifies Verbose mode, displaying full information during the write process.
• The dev option for cdrecord: this specifies the CDRW device to use, the format being controller/SCSI-ID/lun. The lun is usually 0, while for Indigo2 the controller for the device on the supplied external bus is 1. I have a general habit of using SCSI ID 4 for CDROM-type devices and 7 for tape drives, but it’s entirely up to you.
• The speed option for cdrecord: this defines the writing speed, which is normally a power of 2 (and for those wondering about speed=1, well, 1 is just 2^0, so schmeugh!
• The image file to write is the last option on the cdrecord line.

After the write operation is finished, one would then eject the CDR, eg.:

  eject /CDROM2

Note that CDROM2 would be specified for the setup described here since the internal CDROM would already be called ‘CDROM’.
Aliases and Scripts for Easier CDRW Authoring

When writing CDRs it quickly becomes apparent that there are various ways one can make the process even easier. The first thing I did was to make an alias shortcut command for cdrecord, added to my .cshrc (I’ll assume the use of an older device such as a Yamaha 8/8/24 here; adjust the speed setting if you’re using a newer model):

  alias cdr 'cdrecord -v dev=1,4,0 speed=8'

This would allow the use of cdrecord shown earlier to be abbreviated thus:

  cdr stuff.raw

Ideal for the pathalogically lazy.

But so much more is possible than this. First I became tired of manually entering ‘eject /CDROM2′ so I created an alias instead, using the raw SCSI device to make it more independent of how the CD devices may have been named by the OS:

  alias ej    'eject'
  alias e     'eject /dev/scsi/sc0d3l0'
  alias e2    'eject /dev/scsi/sc1d4l0'

‘ej’ is just a general eject command for use with a floppy drive if that is present. Thus, to eject the CDR I just enter ‘e2′. Much easier! And one can use shell symbols to make it happen automatically:

  cd /var/tmp
  mkisofs -R -o stuff.raw stuff
  cdr stuff.raw && e2

Al ot of this just saves typing, but is also faster, helps prevent errors, and begins to introduce aspects of convenience, eg. coming back to find the written CDR already ejected.

Later, I extended this idea to the setup I still use (though now the speed is all set to 16X), namely a script file called ‘cdr’ contained in /usr/local/bin (ie. cdr is not an alias in .cshrc anymore). The script contains the following (remember to make the script executable using ‘chmod u+x’):

  #!/bin/sh
  cdrecord -v dev=1,4,0 speed=16 $1
  apanel -nodisplay -nofork -outlevels 255 && soundplayer -nodisplay -nofork /usr/local/misc/spiral.aifc
  sleep 2
  eject /dev/scsi/sc1d4l0

I should imagine you’re wondering what the apanel/soundplayer command sequence is there for. Its function is to play a short sound file when the CD writing has finished, in this case a few seconds from the track, “Spiral”, by Vangelis. This is done carefully though, in that the volume is set to maximum before the sound is played, neither the apanel or soundplayer GUI applications are displayed when the sound is being played, and the volume is set back to normal after the sound is played. Note that I have an alias called spir which does exactly this command sequence; I use spir quite often as a very simple way of letting me know when a task has completed, eg. a tar operation, or an xfsdump, or a dmconvert process.

After the sound is played, the system waits 2 seconds to give the CDRW time to settle, and then the CDR is ejected.

Thus, to write a CD for which I already have the image available, I just go into the appropriate directory containing the image file and enter:

  cdr filename

and away it goes. When it’s finished a sound is played and the CD is ejected, all without the use of fancy GUI programs or other unnecessary bells and whistles. This kind of operation is a reminder of just how efficient the command line can be. And since it’s just a text command, it can be used in other script files, batched, scheduled, left in the keyboard buffer to follow after other operations, etc.

cdrecord and mkisofs have a vast range of options available, but for most instances of writing a CD, the procedure shown here should do just fine, and the aliases or example scripts can help make the process very easy.
Creating an image of an SGI EFS-format CD

Sometimes one may wish to make a backup copy or clone of an SGI CD which is usually in EFS format. For those CDs which merely contain data, an iso copy of the CD will suffice. This could be done as follows, assuming the CDROM to be copied is mounted as /CDROM:

  mkdir /var/tmp/cd
  cd /CDROM
  tar cvBpf - . | (cd /var/tmp/cd; tar xBpf -)
  cd /var/tmp
  mkisofs -R -o cd.raw cd
  cdr cd.raw

However, some CDs have more than just data, eg. EFS-format CDs which are bootable for doing OS installations or upgrades. These CDs have a volume header which is not visible on the normal partition mounted on /CDROM. To create a CD image which includes the volume header, one must access the CDROM device at a raw level using the ‘dd’ command, as follows:

  dd if=/dev/rdsk/dks1d4vol of=cd.raw bs=512

The ‘if’ field specifies the input file or device (notice there are no spaces either side of the ‘=’ symbol), while ‘of’ specifies the output file or device. ‘bs’ specifies the block size, which for CDROMs should be 512. NB: this operation will work ok if ‘bs’ is not specified, but by default ‘bs’ is set to 1 which means the copy operation would take a very long time! Thus, remember to include the ‘bs’ option and set it to 512.

When the operation has finished, write the image to a CDR in the normal way, eg. ‘cdr cd.raw’. Thus, for example, this procedure is appropriate for creating a backup CD set of the base 6.5 OS installation CDs.
Ejecting a Stuck CD

The most common reason a CD can’t be ejected is because a process somewhere is using it, which usually means a shell window has its current directory somewhere within the CDROM file system. One will see an error message like this:

  eject: The drive is busy.  Make sure no programs are using the drive.

Make sure all shells have their current working directory set to be elsewhere (enter ‘cd’ in every window; check with ‘pwd’) and try ejecting the CD again.

If it still doesn’t eject, even with the low level eject aliases as described earlier, then it’s likely an application or process which was using the CD has gone wrong and is unable to release its hold on the device. Hence, try using the -k option with umount to kill the process which is locking the CDROM:

  umount -k /CDROM

and then try ejecting the CD again.

If that doesn’t work, then the last resort is to shutdown mediad and then just press the hardware eject button on the front of the CDROM, ie.:

  /etc/init.d/mediad stop

…press eject, take out the CD, then restart mediad…

  /etc/init.d/mediad start

Hiding the ‘rr-moved’ Directory

Sometimes the mkisofs command will create an image which, when written to a CDR, results in an extra directory visible in the top of the CD file structure called ‘rr-moved’. It’s not important, but for cosmetic reasons it may be desirable to hide this directory, eg. for production work, etc. (yes, there are companies which use cdrecord to make the commercial CDs they then sell).

To hide the directory, use the -hide-rr-moved option with mkisofs. This will still include the rr-moved directory if mkisofs decides to create it, but the directory will be hidden, ie. it will have a dot prefix (.rr-moved) so that a normal ‘ls’ command action on the CDROM will not show the presence of the directory, which looks much cleaner. A typical usage would be:

  mkisofs -hide-rr-moved -R -o cdstuff.raw cdstuff

I have an alias defined to make this easier:

  alias mk    'mkisofs -hide-rr-moved -R -o'

which shortens the example above to:

  mk cdstuff.raw cdstuff

Erasing/Blanking a CDRW Disc

To erase, or blank a CD, use cdrecord with the ‘blank’ option:

  cdrecord -v dev=1,4,0 speed=8 blank=all

or if you’re confident that a basic erase will suffice then use the fast blanking option thus:

  cdrecord -v dev=1,4,0 speed=8 blank=fast

I have two script files in /usr/local/bin to make this easier: cdba (for blank=all) and cdbf (for blank=fast), which contain respectively:

  #!/bin/sh
  echo "Erasing the CD fully [ALL] at 8X speed..."
  cdrecord -v dev=1,4,0 speed=8 blank=all
  soundplayer -nodisplay -nofork /usr/local/misc/spiral.aifc
  sleep 2
  eject /dev/scsi/sc1d4l0

and:

  #!/bin/sh
  echo "Erasing just the basic structures of the CD [FAST] at 8X speed..."
  cdrecord -v dev=1,4,0 speed=8 blank=fast
  soundplayer -nodisplay -nofork /usr/local/misc/spiral.aifc
  sleep 2
  eject /dev/scsi/sc1d4l0

Miscellaneous

If you’re writing to a CDRW disc, remember that the write speed may be different to the normal write speed and so adjust the values passed to cdrecord accordingly. I use modified versions of the cdr script to achieve this, eg. cdr4 which writes at 4X speed, cdr8, cdr12, etc.
And that’s it! I’m sure there are useful items I’ve left out; I’ll add them when I remember them or hear of other tips. Feel free to email me your own ideas and info.

NOTE: I shall write a section on how to use gcombust to read/record audio CDs at a later date.

How to run 180/300mm scanners on SGI-O2

courtesy of marresearch GmbH  @           http://www.marresearch.com

On SGI computer featuring 68-pin UltraWide-SCSI-adapters (Adaptec 7880),
frequent SCSI-bus resets are observed when a 180/300mm mar scanner is
connected to the SCSI-bus. It is well possible that the computer even
refuses to boot with a mar device connected to it. If the mar device
produces SCSI-bus resets during the boot stage, the operating system will
finally exclude the mar device from the list of available SCSI-devices,
even if the boot process finishes with a running system.
The reason for this is that modern computers are very strict
about sources of electronical noise on the SCSI-bus
to ensure fast transfer rates (up to 80MB/sec) across the bus.

It is therefore very important to follow the specifications for operating
devices
on the SCSI-bus. In particular, SGI says that the SCSI-bus must not
exceed a total length of 3 meters. When more than 3 SCSI-devices are
connected to the bus, the total allowed length reduces to 1.5 meters!
Besides the external cables, for each SCSI device must be added 0.5 meters.

Since the 180/300mm mar scanner features a 50-pin Centronics SCSI-connector,
when connecting it to the 68-pin UltraWide bus, usage of a proper cable
becomes very important. The cable should properly terminate the
extra 18 pins. Cheap cables won't do it. Proper cables may be purchased
from SGI directly. Also, usage of an active terminator on the SCSI-bus
is essential.

If the computer still produces SCSI-bus resets even if the cabling is okay,
the last choice is to lower the speed of the SCSI-adapter. At some stage
you will certainly get a stable system, but the price to pay is that also
other devices connected to that SCSI-adapter will run with lower transfer
rates (which might not be too bad, anyway). If this is not desired, a
solution to that might be the addition of an extra SCSI-adapter (please
note, that the SGI O2 has only very limited extension capabilities. e.g.
or an additional SCSI-adapter or an addition network card).

To modify settings of the SCSI-adapter, follow these instructions
(as super-user):

) Goto to directory /var/sysgen/master.d, i.e.
cd    /var/sysgen/master.d

) Make a backup copy of the file to be modified, i.e.
cp    adp78     adp78.bck

) Search for line:
u_char adp_device_options[ADP78_NUMADAPTERS][16] = {



The following fields will give the (encoded) options for 16 SCSI-devices
each on 7 separate SCSI-adapters. On the O2, the scanner would be
normally connected to "adapter 1" (external bus), while the system disk
and CD-Rom sits on "adapter 0". In most cases, the SCSI-id of the
mar scanner is 2. To find out, type "hinv". The mar scanner shows up as:
Processor: unit 2 on SCSI controller 1

or alike.
In the adp_device_options table, the SCSI-id's start with 0, so if the
mar scanner is set to SCSI-id 2 and sits on adapter 1, the following
lines:

u_char adp_device_options[ADP78_NUMADAPTERS][16] = {
        /* adapter 0 */
        0x83, 0x83, 0x83, 0x83, 0x03, 0x83, 0x83, 0x83,
        0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83,
        /* adapter 1 */
        0x83, 0x83, 0x83, 0x83, 0x03, 0x83, 0x83, 0x83,
        0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83,
        /* adapter 2 */
	...

will be modified to:

u_char adp_device_options[ADP78_NUMADAPTERS][16] = {
        /* adapter 0 */
        0x83, 0x83, 0x83, 0x83, 0x03, 0x83, 0x83, 0x83,
        0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83,
        /* adapter 1 */
        0x83, 0x83, 0x13, 0x83, 0x83, 0x83, 0x83, 0x83,  /* mar on unit 2   */
        0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83, 0x83,
        /* adapter 2 */
	...

Replacing 0×83 by 0×13 for device on unit 2 means:

1. ) enable sync negotiation (0×01)
2. ) enable disconnects (0×02)
3. ) synchronous xfer rate of 8.0 Mhz (0×10)

So the bus will now run at 8.0 MHz only. This is probably not going to reduce
much the performance of other devices like disks and tape drives. 8.0 MHz is
likely to work. If there are still SCSI-bus resets, try to reduce the speed
stepwise to 6.7MHz (0×23), 5.7 MHz (0×33), 5.0 MHz (0×43), 4.4 MHz (0×53),
4.0 MHz (0×63) and finally 3.6 MHz (0×73).

Also, on the O2 the autoprobing of so called the “logical unit number” (lun)
of the mar device must be disabled. In the same file
(/var/sysgen/master.d/adp78), find the next data structure
(adp_probe_all_luns) and modify the corresponding unit number, e.g. modify:

u_char adp_probe_all_luns[ADP78_NUMADAPTERS][16] = {
        /* adapter 0 */
        1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
        /* adapter 1  */
        1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
        /* adapter 2 */
        ...

to:

u_char adp_probe_all_luns[ADP78_NUMADAPTERS][16] = {
        /* adapter 0 */
        1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
        /* adapter 1  (Do not probe lun on the mar on unit: 2 )*/
        1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
        /* adapter 2 */
        ...

After these changes, the kernel needs to be reconfigured. To do so, run:

/etc/autoconfig -f

reboot…