%p or $devpath or DEVPATH is the path under /sys, but without the leading "/sys." E.g., the device path will be /sys/block/sdc, and DEVPATH will be "/block/sdc." $kernel or %k is the path *under* dev, e.g., bus/usb/002/017, so /dev/%k is the actual path to the device name.
Using Program. PROGRAM runs *before* the anything is done in the rule. If PROGRAM fails, the entire rule fails. When I was making errors in PROGRAM -- for example, when I was using the wrong SUBSYTEM, or I didn't give a full path name to umount -- then the SYMLINK wasn't created because PROGRAM returned an error.
So, let's say I want to mount a flash drive. I don't need an external script; I can use:
SUBSYSTEM=="block", ACTION=="add", SYSFS{product}=="Flash Disk", SYMLINK="ums", ENV{flashdrive}="%p", RUN+="/bin/mount -t vfat -o user,sync,umask=0000 /dev/%k /ums"
Note that you must give the full path name to "mount," otherwise RUN will assume it's a udev script and try to find it in /lib/udev or some other udev-specific location.
If I'd used "PROGRAM" instead of run, then udev would attempt to execute mount before adding the /dev entry, PROGRAM would return a non-zero exit code, and the rule would not execute and the /dev entry would not be made. (Well certainly the SYMLINK would not be made; it's possible the /dev entry is made, but I don't think it is.)
The man page mentions the ENV, but what are the contents of this mysterious variable? They can be viewed by using "udevmonitor --env" -- it gives a printout of each ENV variable as it's used/set. I suspect that there are more than the ones we see...
Aras Vaichas explains that "SUBSYSTEMs are what you find in /sys/class/ /sys/block/ /sys/bus/, e.g. usb, scsi, serio, etc." You can see the SUBSYSTEMs by using "udevmonitor --evn" and looking for SUBSYTEM. The PHYSDEVDRIVER variable is the associated kernel module.
Finally, setting GROUP for a device you've hotplugged. Instead of using an external script as was the case with hotplug, you can use a simple rule instead. This is how I set GROUP when I mount my USB-enabled camera:
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="3051", GROUP="camera"
The trick is knowing that it's the "usb_device" SUBSYSTEM that creates the USB device entry that gtkam and libgphoto2 use, e.g., /dev/usb/002/017. Finding out what SUBSYSTEM to use is a trail-and-error process, but udevmonitor --env does display the /dev entry when it's created, and that's a very good start.
]]>First of all, I suggest you read Daniel Drake's introduction to udev rules. As he suggested, I used udevinfo to find an appropriate SYSFS. Please note that udevinfo is a bit buggy: you have to use "udevinfo -q path -a" and not "udevinfo -a -q path" if you want full information.
One you're finished, here's some additional information. Kay Sievers explained to me that 'Sysfs values are not readable at remove, cause the device directory is already gone. You need to match against properties which you can see in udevmonitor --env or you need to store a custom key with ENV{key}="value" in the database, which is imported on remove.'
In order to add and remove the flash drive, I use the following udev rules (modified 20051207 to add SUBSYSTEM):
SUBSYSTEM=="block", ACTION=="add", SYSFS{product}=="Flash Disk", SYMLINK="ums", RUN+="/etc/hotplug/usb/ums", ENV{flashdrive}="%p"
SUBSYSTEM=="block", ACTION=="remove", ENV{flashdrive}=="%p", RUN+="/etc/hotplug/usb/ums"
The first rule sets, on an "add," the custom environment variable "flashdrive" to the value of DEVPATH (%p). The 2nd rule checks, on a "remove," to see if the devpath that's being removed is the one for the flash drive -- if so, the designated script runs.
Which is great. Something similar works for the iRiver mp3 player too, expect that I use a different SYSFS. Now the problem becomes getting the ums script to work.
Here's what I use. This isn't a perfect solution, because udev calls the ums sript multiple times (once for usb and once for scsi_generic events). I could eliminate these multiple calls, but I've decided not to bother. Note added 20051207: By adding SUBSYTEM, I call the script just once. The trick is finding the right SUBSYSTEM; several are called during the plugin event. Eventually, I discovered that the "block" is the best one to use; it seems to be the one that handles all devices that need to be block-accessible, i.e., to act as if they were drives.
To summarize what the script does: if I receive an add event, and the expected /dev/ums is available, I mount the device to the /ums mount point. On a remove, I umount if it's mounted.
By the way, I've been reluctant to remove the legacy devfs code from the script until this script and udev have been in service for a while; when using udev, /dev/ums is either there or not, and there's no need to check other paths, which makes the "else" path for defining NEWDEV unnecessary.
To make this script work for an iriver, change "ums" to "iriver" in appropriate places.
Script:
#!/bin/bash
##############################################
# iRiver hotplug script
# Written by Stefan Månsby (stefan@nis.nu)
# Version: 0.05
##############################################
# modified MY 2005-01-09
# modified for udev by Moshe Yudkowsky 2005-11-30
MOUNTDIR="/ums"
LOG=/var/log/usb-hotplug.log
ERRCODE=0 # for debugging, do not report errors
lap=$(date --rfc-3339=ns)
# defvs: DEVICE seems pretty useless
# need to search for "host*" in DEVPATH
# udev: no need for host* at all
plug() {
echo "...$lap: $DEVICE, $DEVPATH requested" >> $LOG
NEWDEV=""
((count=10))
if [ -b /dev/ums ]
then
NEWDEV=/dev/ums
else
while [ -z $NEWDEV ]
do
# look for host* on DEVPATH
NEWDEV=$(find /sys${DEVPATH} -name "host*") # find scsi host name
[[ ! -z $NEWDEV ]] &&
NEWDEV=$(basename $NEWDEV) # find at $(date)" that host
[[ $count -le 0 ]] &&
{
echo "...$lap: unable to find $NEWDEV in /sys${DEVPATH}, exiting" >> $LOG
exit $ERRCODE # stop if too many attempts
}
((count -=1))
echo "...$lap: $DEVPATH was not ready, try again" >> $LOG
sleep 1
done
NEWDEV=/dev/scsi/${NEWDEV}/bus0/target0/lun0/disc
fi
echo "...$lap: We wil use device $NEWDEV" >> $LOG
((count=10))
while [ ! -b $NEWDEV ]
do
echo "...$lap: wait for $NEWDEV to show as device, $count attempts left" >> $LOG
sleep 1
((count -= 1))
[[ $count -le 0 ]] &&
{
echo "...$lap: cannot get device, exiting" >> $LOG
exit $ERRCODE
}
done
echo "...device $NEWDEV is ready" >> $LOG
if [ -b $NEWDEV ]
then
{
echo "...$lap: $(date) mounting $NEWDEV" >> $LOG
# mount when plugged in
if (echo "..."; mount -t vfat -o user,sync,umask=0000 $NEWDEV $MOUNTDIR) >>$LOG 2>&1
then
echo "...$lap: mount succeeded" >> $LOG
else
echo "...$lap: mount failed" >> $LOG
fi
}
else
echo "...$lap: $DEVICE requested, unable to mount or find $NEWDEV" >> $LOG
reason=$(file $NEWDEV)
echo "...$lap: Reason: $reason" >> $LOG
fi
# create REMOVER script to umount when it unplugs
# if [ ! -b /dev/ums ]
# then
#
# :> $REMOVER
# echo "umount -f $MOUNTDIR >> $LOG" >> $REMOVER
# echo "echo \"$(date) $(time) unmounting /ums\" >> $LOG" >> $REMOVER
#
# chmod +x $REMOVER
# fi
#
}
unplug() {
if [ ! -b /dev/ums ]
then
mount | grep --quiet ums && umount $MOUNTDIR && echo "...$lap: umount suceeded"
fi
}
# start script
# lap=$(date --rfc-3339=seconds)
echo "ums/$lap: udev requested $ACTION" >> $LOG
case $ACTION in
"add") plug ;;
"remove") unplug ;;
*) echo "...No action taken" >> $LOG ;;
esac
exit 0
]]>Here's a summary of the problem I encountered and how I resolved it.
Problem: as I booted up, I got the usual deluge of reports; then I got three error messages:
/sbin/init: 432 cannot create /dev/null
/sbin/init: 433 cannot open dev/console
Kernel panic -- not syncing: Attempted to kill init!
After a bit of research and some asking around, I found that the answer was as follows.
There's a difference between devfs and udev. Devfs makes the
"console" and "null" files available by the time the files are needed
during the boot. udev starts later in the boot cycle, so you must supply your own copy of /dev/console and /dev/null. (There's a facility in udev that's supposed to create these files in advance (/etc/udev/links.conf in the Debian package), but it didn't work in my case.)
Therefore, before trying to boot using udev only, make certain you have a "console" and "null" file in /dev. Of course, if your system is running, you have these files now -- but the question is, were they part of the /dev directory, or did devfs put it there? Here's how to check.
* First, mount the root directory someplace other than /, so that the /dev
directory can be examined as a standalone -- so it can be seen as it looks without stuff that devfs puts there. As root, issue the command:
# mount -o bind / /mnt
(where /mnt is some random mouting point).
* Next, look at /mnt/dev. You need to have two special files there, console and null:
crw------- root root 5, 1 Nov 28 16:50 console
crw-rw-rw- root root 1, 3 Nov 28 16:51 null
If you have them already, you're all set. On my system, I had "null" and it was *not* a "c" (special character) file; it was an ordinary file. I got rid of that file and issued the following commands to create console and null:
# mknod -m 660 console c 5 1
# mknod -m 660 null c 1 3
* Unmount the / file system:
# umount /mnt.
* Make certain you have udev! Linux 2.6.14-2 requires udev to boot, but you are responsible for actually installing udev.
* Once /dev/console and /dev/null exist, you can boot using udev only. (For example, on my system, a boot using udev only is done by removing the "devfs=mount" command from lilo.) There's other stuff to do to convert completely to udev, but this gets you started.
]]>I have hotplugging installed on my Debian 2.6.9 version Linux system. Inside the /etc/hotplug directory is one file to examine, one file to alter, and one file to add.
Hotplugging works as follows. When I plug something into the USB bus, it generates an "add" event, and when I remove something it generates a "remove" event. The usb.agent file runs on either of these events, and is called with a list of information about the event:
idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
The usb script also has access to these variables:
# Kernel USB hotplug params include:
# ACTION=%s [add or remove]
# DEVPATH=%s [in 2.5 kernels, /sys/$DEVPATH]
# PRODUCT=%x/%x/%x
# INTERFACE=%d/%d/%d [ for interface 0, if TYPE=0/*/* ]
# TYPE=%d/%d/%d
# And if usbfs (originally called usbdevfs) is configured, also:
# DEVFS=/proc/bus/usb [gone in 2.5]
# DEVICE=/proc/bus/usb/%03d/%03d
There's no formal documentation, as far as I can tell, what these mean, even though they are crucial to get hotplugging to work. Don't despair -- this note supplies these missing links.
The usb.agent executable now decides what to do next. It looks in usb.distmap and usb.usermap to determine if there's anything to be done.
The entries in usb.usermap and usb.distmap are as follows:
usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
"usb_module" is the name of an executable to run *if* the current event matches the information in the rest of the line. What has to match? "match_flags" tells you which items from the list must match:
USB_MATCH_VENDOR=$((0x0001))
USB_MATCH_PRODUCT=$((0x0002))
USB_MATCH_DEV_LO=$((0x0004))
USB_MATCH_DEV_HI=$((0x0008))
USB_MATCH_DEV_CLASS=$((0x0010))
USB_MATCH_DEV_SUBCLASS=$((0x0020))
USB_MATCH_DEV_PROTOCOL=$((0x0040))
USB_MATCH_INT_CLASS=$((0x0080))
USB_MATCH_INT_SUBCLASS=$((0x0100))
USB_MATCH_INT_PROTOCOL=$((0x0200))
To pick a non-random example: Let's say I have a UMS flash drive and I want to run a particular script every time it's plugged in. I used "match vendor" and "match product", which makes match_flags = 0x3, and if that UMS device is plugged in, a particular script runs.
The real mystery is how find the idVendor, idProduct, etc. I found that by using lsusb -v:
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0ea0 Ours Technology, Inc.
idProduct 0x2168 Transcend JetFlash 2.0
bcdDevice 2.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
so the line in usb.usermap now looks like this:
ums (module to run) 0x3 (what to match) 0x0ea0 (vendor ID) 0x2168 (product ID)
and the rest all zeros. In actuality, the line looks like:
ums 0x0003 0x0ea0 0x2168 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000
If I were feeling clever, and I may feel clever some day, I might decide to make a universal flash, mass storage mounting hotplug system. To do that, I'd use the rest of the lsusb -v information:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Clearly, could use bInterfaceClass to select "mass storage" and write a module of that type. But I digress.
So, when I plug in my UMS device, usb.agent looks into user.usermap, finds the matching idVendor and idProduct, sees that it need only match those two, and attempts to run the module named on that line. That module is called "ums," and it resides in /etc/hotplug/usb.
"ums" accomplishes two tasks: (a) it mounts the flash drive and (b) has a script to umount the flash drive on disconnect.
Here's the ums script, part by part. First I create a log file:
MOUNTDIR="/ums"
LOG=/var/log/usb-hotplug.log
Next I try to find where this usb device is mounted, which is *really hard* to do. On my system, on each hotplug, devfs and sd_mod conspire to mount the drive on a different part of the SCSI chain. My goal is to find the SCSI device and mount it.
I log the DEVICE and DEVPATH that's inherited from the usb.agent script:
# DEVICE seems pretty useless
# need to search for "host*" in DEVPATH
echo "$(date) $(time) $DEVICE, $DEVPATH requested" >> $LOG
Next, I search along DEVPATH to find a "host[0-9][0-9]" directory. DEVPATH looks like "/devices/pci0000:00/0000:00:10.3/usb4/4-2/4-2:1.0" , and it must be preceeded by "/sys" to point to a real directory structure. If I find a directory called, e.g., host21, I've seen on my system that this means that the flash drive is associated to /dev/scsi/host21/bus0/target0/lun0/disc.
NEWDEV=""
((count=10))
while [ -z $NEWDEV ]
do
# look for host* on DEVPATH
NEWDEV=$(find /sys${DEVPATH} -name "host*") # find scsi host name
NEWDEV=$(basename $NEWDEV) # find just that host name
[[ $count -le 0 ]] && break # stop if too many attempts
((count -=1))
echo "$(date) $(time) $DEVPATH was not ready, try again" >> $LOG
sleep 1
done
This goes in a loop. The USB event happens immediately, but it takes time for sd_mod to create the SCSI entry, and so if it's not ready first time around I wait a second and try again, up to 10 times. It's never taken more than once.
NEWDEV=/dev/scsi/${NEWDEV}/bus0/target0/lun0/disc
The name of the SCSI drive that corresponds to the usb flash drive
((count=10))
if [ ! -b $NEWDEV ]
then
echo "$(date) $(time) wait for $NEWDEV to show as SCSI device" >> $LOG
sleep 1
((count -= 1))
[[ $count -le 0 ]] && break
fi
Wait to make certain that the drive is created by the SCSI software.
Mount the drive if it exists:
if [ -b $NEWDEV ]
then
{
echo "$(date) $(time) mounting $NEWDEV" >> $LOG
# mount if plugged in
mount -t vfat -o user,sync,umask=0000 $NEWDEV $MOUNTDIR >>$LOG 2>&1
}
If it doesn't exist, write a faliure to the log file:
else
echo "$(date) $(time) $DEVICE requested, unable to mount or find $NEWDEV" >> $LOG
reason=$(file $NEWDEV)
echo "Reason: $reason" >> $LOG
fi
usb.agent expects a script named $REMOVER to exist which explains what to do when the device is unplugged. Create this script, which in our case will umount the drive, by echoing instructions into the file $REMOVER:
# create REMOVER script to umount when it unplugs
:> $REMOVER
echo "umount -f $MOUNTDIR >> $LOG" >> $REMOVER
echo "echo \"$(date) $(time) unmounting /ums\" >> $LOG" >> $REMOVER
chmod +x $REMOVER
If you're curious, REMOVER will be found in /var/run/usb.
The reason for this roundabout way of finding the SCSI disk is because there doesn't really seem to be any other way of extracting the information. There's no file that I've found in the USB chain that says "this USB device is represented by the SCSI deviced named 'X'."
Log output:
Mon Jan 10 10:10:50 CST 2005 /proc/bus/usb/004/023, /devices/pci0000:00/0000:00:10.3/usb4/4-2/4-2:1.0 requested
Mon Jan 10 10:10:50 CST 2005 /devices/pci0000:00/0000:00:10.3/usb4/4-2/4-2:1.0 was not ready, try again
Mon Jan 10 10:10:51 CST 2005 mounting /dev/scsi/host21/bus0/target0/lun0/disc
At the same time, from the messages log:
Jan 10 10:10:50 bagpipes usb.agent[12238]: usb-storage: already loaded
Jan 10 10:10:50 bagpipes kernel: SCSI device sdb: 128000 512-byte hdwr sectors (66 MB)
Jan 10 10:10:50 bagpipes kernel: sdb: assuming Write Enabled
Jan 10 10:10:50 bagpipes usb.agent[12238]: ums: loaded successfully
Jan 10 10:10:50 bagpipes kernel: /dev/scsi/host21/bus0/target0/lun0:
Jan 10 10:10:50 bagpipes kernel: Attached scsi removable disk sdb at scsi21, channel 0, id 0, lun 0
Jan 10 10:10:51 bagpipes scsi.agent[12240]: disk at /devices/pci0000:00/0000:00:10.3/usb4/4-2/4-2:1.0/host21/21:0:0:0
When my Ethernet insterface didn't work at all after booting into 2.6.8, I used "lsmod" to determine what modules were installed, and after loading and unloading modules, starting and stopping networking, and reading /var/log/messages to see how the boot went, discovered that bcm5700 wasn't loading but did work if loaded. This was very puzzling, because /etc/modules.conf was very explicit in trying to load bcm5700 for the eth0 interface.
I went to the /etc/modutils directly and tried to get the eth1394 (which is listed as "ip1394" in the log for unknown reasons) to stop loading. I used:
alias eth1393 off
alias tg3 off
to get these two modules to never load. (The commands went into a file called "networking-A7V8X" that I use to control kernel modules related to networking.) I rebuilt /etc/modules.conf using update-modules, rebooted the machine — and the modules loaded anyway.
In other words, /etc/modules.conf was being ignored by modprobe during boot time.
Eventually I stumbled across the answer by reading the man page for modprobe instead of just skimming it. Modprobe has changed between 2.4 and 2.6. The old information my /etc/modutils and /etc/modules.conf is not read under 2.6, and the Debian upgrade process won't automatically migrate my custom configurations from 2.4 to 2.6.
2.6 uses a /etc/modprobe.d directory, and it does not need a "/etc/modprobe.conf" file; it reads all the appropriate *.conf files and compiles the information at boot time. Very handy, actually.
To solve the problem of the eth1394 and tg3 grabbing the Ethernet interface, I used the "alias x off" commands I list above, placed them in a file in /etc/modprobe.d, and rebooted. This time the system functioned as expected and the Ethernet system used the proper bcm5700.ko driver.
I realize that there are other ways to force a particular driver/module to associate with a particular physical interface (use the "mapping" keyword in /etc/network/interfaces), but this one works for me as I don't need eth1394 for anything at the moment.
]]>To start, get the source of the Broadcom driver:
apt-get install bcm5700-source
This will install itself in /usr/src as a gzip file. As root, go to the /usr/src directory and unpack the file:
tar zxf bcm5700-source.tar.gz
This creates a directory modules, under which will be a directory bcm5700 which contains the source code.
The next step is to compile the bcm5700 source code. You don't need to be running 2.6.x to do this. You do need the current headers of your target kernel image. E.g., if you want bcm5700 to work for 2.6.8-1-k7, you will need the kernel headers for 2.6.8-1-k7. You don't need the source for the entire kernel.
To get the kernel headers, use
apt-get kernel-headers-2.6.8-1-k7
or whatever is appropriate for your target kernel. The headers will appear in your /usr/src directory as well.
You need to make /usr/src/linux point to these kernel headers. On my system, /usr/src/linux is simply a symlink to a real directory. I removed the old symlink (rm linux) and used
ln -s kernel-headers-2.6.8-1-k7 linux
to create the symlink. To compile the bcm5700.ko module, go to the /usr/src/linux directory and type
make-kpkg modules
This will make a Debian package in the /usr/src directory. You can then use
dpkg -i bcm5700-module-2.6.8_7.3.5-3+10.00.Custom_i386.deb
(or whatever the Debian is called on your sytsem) to install the driver. However, I could not figure out how to persuade make-kpkg to give the proper version to the Debian package; as you can see above it thinks it made a driver for 2.6.8, not 2.6.8-1-k7. This means that when I did the dpkg -i to install the Debian package, Debian failed partway through and put the bcm5700.ko file into /lib/modules/2.6.8, instead of it's proper place in /lib/modules/2.6.8-1-k7. No worries -- I copied the driver from there to /lib/modules/2.6.8-1-k7/kernel/drivers/net/bcm5700.ko, and I was ready to go.
That's it for creating the driver module. Fairly straightforward.
However, that doesn't mean that the driver actually loaded when I booted up the sytsem &mdash something else grabbed control of the Ethernet interface. See my next technical note, about migrating from Linux 2.4 and its system of /etc/modules.conf to Linux 2.6 and its system of /etc/modprobe.d, for details on how to resolve this little problem.
]]>Last night and today I received several bounce messages, each containing a zip file that I purportedly sent to myself. The bounce messages didn't smell quite right, since they lacked copies of the original headers in the bounce message. Of course I discarded the entire message including the zip file immediately — I wasn't about to run a virus.
All the bounces theoretically had originated somehow with Pobox, the service I use to "wash" my email and stem off some of the flood of spam. And that should have raised a red flag, because pobox generally has impeccable bounce messages. And looking back after the fact, I can see that all the bounces were forged bounces.
Forged bounces? Why send forged bounces?
Part 2 of the exploit just arrived, a message "from pobox" which states:
> Your account was used to send a large amount of junk email messages during this week.
> Obviously, your computer was compromised and now runs a trojaned proxy server.
>
> Please follow our instruction in order to keep your computer safe.
and includes a zip file -- which, by the way, doesn't trip online spam detectors. The message immediately tripped my internal bogosity detectors, and that's when I noticed that the message didn't originate with Pobox.
I've notified pobox, but this is the most sophisticated phishing expedition I've seen -- even if it doesn't technically count as phishing. The goal is to get the recipient to open the zip file included in the bounce messages.
It's clever, and I suspect it will be very effective. I've seen it against Pobox, but I'm starting to get bounce messages that lead me to believe it's about to be launched against other sites as well.
Further information, added 07-27: It seems that this worm is a variant of My.Doom, and it actually is not a coordinated attack; it's just a coincidence that I got the bounce messages before I received the your-machine-is-compromised messages. I wonder how long until we see more sophisticated, coordinated attacks?
]]>Claria, formerly Gator, installs malware — specifically, "adware" that spies on your Internet browsing and pops up a window when you hit specific web sites. For example, L. L. Bean alleges in a lawsuit that Nordstrom and J. C. Penny, former Claria customers, would pop up ads for those companies when a potential customer visited the L. L. Bean web site. (Claria has sued L. L. Bean, in return, for filing a "sham lawsuit.")
How does Claria and WhenU software get onto a computer? Usually as part of installation of other software. A download of a "web browser search tool" will have a note, buried deep in the disclaimers, that the software spies on your web browsing and pops up ad windows. This makes installing the malware legal. Despicable, but legal.
In my experience, malware is one reason that people think their computers are "slowing down." I've done troubleshooting on slow computers only to find that malware (not necessarily Claria's and WhenU's) has made the computer utterly unusable. I believe that a good number of people purchase new computers because their old ones couldn't support all the malware loaded on it.
So, why blame Verizon? Verizon, by purchasing ads through Claria, helps to support the malware industry. They aren't ashamed of what they've done; their spokeman said that "it's much more efficient" than other forms of advertising. In other words, Verizon supports malware, and by doing so encourages an despicable industry that does despicable things.
Here's a list, as published in the Wall Street Journal and gleamed by me from the Claria web site, of current and former customers of Claria and WhenU:
If you have a business relationship with one of these companies, you might want to make them of your opinion of malware.
]]>Our inaugural blunder comes from Nosa Eke, publisher of "Call Center Times." After sending me not just one but six copies of a piece of spam, I sent her a complaint and asked to be taken off her mailing list.
Her response? "If you have such a problem with being contacted," she writes, "have you considered removing your name as the point of contact in listings such as Buyer's Guides etc..? [sic]". Not only does she implicitly confess to harvesting my email address from a web site -- something I already knew -- she has the chutzpah to tell me that it's my tough luck. And her command of the English language makes me wonder about the magazine she publishes.
After getting more than a few more missives from her, I put here onto "autoreponse." It's a little script that I wrote that sends a couple of thousand complaint emails back to the originator, triggered by spam to me. Remarkably, she somehow managed to find the time to remove me from her list after just one autoresponse.
Nosa Eke's email address is neke@callcentertimes.com. You might want to put it on your blacklist.
]]>Voxeo also offers access via 800 numbers and ordinary numbers; like most places they require access via a PIN. However you can request a unique telephone number for an application, which is convenient if you want to have other people access your demo. Voxeo also assigns each application a SIP telephone number.
What I like most about Voxeo is their "Extreme Support." Email to customer service is answered very quickly, generally within the hour, and their customer support people are very, very knowlegable. And it's also clear that their managers monitor customer support to make certain that questions are answered. Since there has never been and probably never will be a manual that answers all my questions, swift and accurate customer support is wonderful.
Tellme offers an online server for developers, but for some reason it's impossible (at least for me) to find it through their regular home page.
Tellme offers VoiceXML 2.0, tutorials, documentation, code samples, some space on their server to store application (I haven't used it much), a way to access scripts on your own server, 800 access numbers (not unique), and pre-recorded voices. You can call the server to record your own prompts.
Tellme also offers a syntax checker, which lets you check your application's syntax without actually running it.
I haven't actually tried Voicegenie's online server just yet. Voicegenie offers VoiceXML 2.0, documentation, an online syntax checker, a grammar wizard to help develop grammars, recording prompts over the phone, documentation, tutorials, sample code, and forum-based support.
Voicegenie does have some oddities. Some of their links lead to Voicegenie-supported websites that haven't been updated with developer information since 2002. And their developer agreement doesn't let developers "disclose results of any benchmark tests of such development tools to any third party without VoiceGenie Technologies' prior written approval."
BeVocal's claim to fame is that its online server has voice biometrics, such as speaker identification and verification. It makes for a nice demo (you can get one from here on my web site).
Otherwise, BeVocal offers everything: tutorials, documenation, online syntax checking, debugging tools, and a tool that lets you interact with your application in text mode. Files can be located on their server or your server. Support is via their forums, with turnaround times of up to one day.
I've used VoiceXML interpreters running on my laptop to demo VoiceXML; for example, IBM's VoiceXML interpreter downloaded from IBM Alphaworks; CCXML is available both at IBM Alphaworks and elsewhere. However, I find that running my applcations on a remote online server that's connected into the PSTN — and now SIP! — provides me with tools that otherwise simply aren't available.
]]>For use with a laptop when traveling, or for use when people don't have a hardware firewall, I use ZoneAlarm from Zonelabs. I use ZA to protect the PC from intrusion — ZA can be configured to check your email, but I use a different program to screen for viruses.
For home installations I prefer hardware firewalls that also do NAT. I do not like D-Link or Belkin firewalls, the former because the "D" seems to stand for "Don't", and the latter because of what I consider egregious corporate misbehavior.
I use AntiVir. Antivir seesm to do a credible job of finding and cleaning viruses. AntiVir also has a "scheduler" built-in that lets you schedule when to run a scan of the disk automatically; twice a week is sufficient in my opinion. AntiVir also does a very credible job of downloading and installing updates automatically, also using a scheduler.
Antivir is what I recommend to defend against downloading virus emails, files, etc. Set it to load and run on startup. And make certain that you never have two antivirus programs running at the same time.
I recommend two packages, Lavasoft's AdAware, and Spybot. Both programs have their strengths and weaknesses, so it's best to use both of them from time to time.
The main defense against malware is to not load disreputable programs onto your computer; I don't have problems with malware on my machine (that I'm aware of). Spybot lets you "immunize" Internet Explorer against malicious software downloads.
For a browser, I recommend Mozilla. Among other things, Mozilla has exellent security features built-in, such as a setting that surpresses pop-up windows.
Mozilla does include an email program, but for business use I prefer to use a separate program for email. I use Eudora. Just as an example, a colleague of mine was being driven crazy by spam; I had him install Eudora, and its junk-mail filters immediately caught 99% of the spam.
One of the ways that viruses and malware take over your computer is through "startups," programs that run when you turn on your computer. For that matter, several otherwise well-behaved programs attempt to run at startup and put themselves into your PC's "tray." By running at startup the programs chew up memory and CPU on your computer, usually for no good reason (other than advertising the existence of the program). Very occassionally a program will attempt to register a one-time, post-install, post-bootup cleanup program. Startup control is a way of thwarting programs that attempt to register themselves to run at startup.
I use Mike Lin's StartupMonitor, which informs me when a program attempts to register itself to run at startup.
Startup Control Panel from the same author is even more useful: It lets me see what's already installed to run on startup. And I can turn things off (and on again afterwards) which is extremely useful when cleaning up a virus.
There's nothing quite like sitting down at someone's computer, running a virus scanner, and finding 78 copies of different viruses. Here's some of the tools I've used (aside from the anti-virus and anti-malware scanners) to clean up infected computers.
One note about cleanups: Some viruses are very, very nasty indeed. They erase copies of anti-virus software and try to prevent you from downloading new ones. They keep multpile copies of themselves running, and they change their names to make them harder to erase. A really persistent infection -- and many people have these -- requires that the computer be started in "safe" mode, which is done by following the instructions for your PC (often it's to use the F8 key on startup). In safe mode, nothing much loads on the computer, and you can then run the antivirus and anti-malware software. Sometimes this requires several cycles to catch all the problems.
Startup Control Panel, mentioned in the previous section, is a very useful tool to clean up malware problems, and of course to get useless junk out of the "startup tray."
HijackThis recently let me rescue a system that simply couldn't be cleaned any other way. HijackThis lists everything that attempts to intercept your web browser. This is not an analysis tool -- you have to decide for yourself if you think a particular item is dangerous or beneficial! Use with extreme care.
(Note: Here's a malware test. I had a firewall connected to the PC, but the firewall was not connected to the network. When I tried to use the browser on the PC to access the firewall, I would time out &mdash it took forever. It was because the browser was being hijacked, and the slowdown happened as the malware tried to get to the net, not realizing that I was only connected to the firewall's web page server and not the 'net. If you have these symptoms, you probably have malware. And HijackThis was the only way I was able to fix it.)
Dr. Delete is a tool to remove a file at next bootup. Good for getting rid of a file that simply seems to be stuck on your system.
lspfix is a tool that fixes the TCP/IP chain if it's been damaged by malware. I've never had to use it.
And as a nice way to get some junk off your system, CCleaner removes temp files from across the system. And yes, I think the program would be a lot more popular if the name were less indelicate.
]]>