Real World Example: Converting a package with Alien

At my office we have a new printer, a Dell C3765dnf Color Multifunction printer. This was not my choice of printer, but it is what we were given, so I needed to make the most of it. Unfortunately, I didn’t find any suitable ppd drivers in Cups for it. Not only that, but a search of the internet did not lead me to any ppd files either. I tried everything I could think of, from searching for Debian packages containing Dell, to unzipping Mac OS files to look for it. Nothing. The closest thing I could find was an RPM as Dell’s token support for Linux.

Well, at least that is something. I can work with that. I’ve used alien before to convert packages from one distro to another, but it usually doesn’t work if you lack the dependencies. In this case, however, the rpm simply installs the ppd’s which cups uses, so I was pretty sure I wouldn’t have a dependency problem. So here’s what I did:

$ sudo apt-get install alien

$ alien -d Dell-C3765-Color-MFP-1.0-3.noarch.rpm
Must run as root to convert to deb format (or you may use fakeroot).

I left this in so you could see that you needed root permissions to use alien.

$ sudo alien -d Dell-C3765-Color-MFP-1.0-3.noarch.rpm
Warning: Skipping conversion of scripts in package Dell-C3765-Color-MFP: postinst postrm
Warning: Use the –scripts parameter to include the scripts.
dell-c3765-color-mfp_1.0-4_all.deb generated

$ sudo dpkg -i dell-c3765-color-mfp_1.0-4_all.deb
Selecting previously unselected package dell-c3765-color-mfp.
(Reading database … 109097 files and directories currently installed.)
Preparing to unpack dell-c3765-color-mfp_1.0-4_all.deb …
Unpacking dell-c3765-color-mfp (1.0-4) …
Setting up dell-c3765-color-mfp (1.0-4) …

After that, I loaded up cups in my browser with localhost:631, and added my new printer. The new driver showed up at the top of the Dell list! For once, something easy when working with alien.

Linux – keep it simple.

Real World Example: Another excuse to use tcpdump

This happened a while back, but I really can’t stress enough how great a program TCPdump is. A great way to show it is to include it in a real world example where I actually used it at work.

This was yet another simple problem that had to be addressed on one of the simulators at work. Once again, poor documentation left us in the dark with what was actually happening between the different hosts on a network and an environmental control unit sensor, which was supposed to relay information about the current temperature in the box to ultimately be displayed to the user on the IOS host computer.

The problem was that it would display *sometimes* and often erroneously. It would often seem to be “outdated” information, as in, that was what the temperature was a minute or two ago, especially a problem when you are trying to constantly monitor the temperature during a problem that leads to overheating. So, we dove in with TCPdump to find out how often it was updating the hosts, and who it was updating specifically. We already knew the IP address of the unit, as it has a digital display that told us so. We also knew where the information was displayed, on the IOS host, but we wanted to make sure the information didn’t stop somewhere else along the way.

#tcpdump -avvv -i eth0 src |tee ecutcpdump.txt

05:43:38.313916 IP (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto TCP (6), length 40) > IOS.local.2770: Flags [.], cksum 0x6d89 (correct), ack 17, win 512, length 0
05:43:38.346370 IP (tos 0x0, ttl 64, id 3, offset 0, flags [none], proto TCP (6), length 63) > IOS.local.2770: Flags [P.], cksum 0xc0a0 (correct), seq 1:24, ack 17, win 512, length 23
….r.;.nP……………. .B…B……..
05:43:38.563462 IP (tos 0x0, ttl 64, id 4, offset 0, flags [none], proto TCP (6), length 40) > IOS.local.2770: Flags [.], cksum 0x6d71 (correct), ack 18, win 512, length 0
05:43:39.076462 IP (tos 0x0, ttl 64, id 7, offset 0, flags [none], proto TCP (6), length 40) > IOS.local.2771: Flags [.], cksum 0x9427 (correct), ack 17, win 512, length 0
05:43:39.106468 IP (tos 0x0, ttl 64, id 8, offset 0, flags [none], proto TCP (6), length 63) > IOS.local.2771: Flags [P.], cksum 0xe734 (correct), seq 1:24, ack 17, win 512, length 23

Here we see our answers. First, it appears to be communicating with the IOS.local.2771 host, which correlated with the IOS host computer where the information was displayed. This was great to know, as it did not go through several hosts to get to the displaying host for the user. Second, it appears that the unit is communicating frequently. In fact, it seems to be communicating at least 3 times per second, as you can see in this section of the log file that I collected.

Ultimately, the problem turned out to be a software issue with the program that displays the information, but it was a good first step to rule out problems of communication being too sparse or going through multiple hosts on the network to reach the destination. Just another easy real world example of using TCPdump with Linux.

Linux – keep it simple.

Real World Example: UDEV rules for cell phones

The other day, when using adb to communicate with my phone, I had a problem where my laptop would not connect to my phone.

# adb devices
List of devices attached

Odd, it should have listed the device serial number. So I checked out lsusb to see if the phone was showing up at all, which it was:

# lsusb
-other stuff-
Bus 001 Device 004: ID 22b8:41da Motorola PCS

After some research, I realized that I needed some rules for this
device, and found that one guy did something similar for his nook. I
stole what he did, but changed it for my phone.

# touch /etc/udev/rules.d/99-android.rules
To create the file.

# echo “SUBSYSTEM==usb, ATTR{idVendor}==22b8, MODE=0666, OWNER=user #
motorola” >> /etc/udev/rules.d/99-android.rules
# service udev restart

Now when I run adb devices, I can actually communicate with my phone:

# adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
04039C4E19009019 device

Just a quick and dirty real world example.

Linux – keep it simple.

Real World Example: Determining an APC battery backup IP Address with tcpdump

While not overly complicated, we ran into a problem at work the other day relating to an APC battery backup unit. The unit in question was an APC Symmetra PX. The problem was that it was connected to the network, but we didn’t know what the IP address of the unit was. Nor did we know if/what the unit was communicating to the other computers on the network. We could not change the configuration of this unit, but we needed to get into the web gui for maintenance purposes.

Thus started our short adventure. Now there are many tools to complete this task, but being a Linux enthusiast, I chose TCP dump on a Debian laptop. We plugged the laptop into the hub that the APC was on, which then whent on to a network switch and a bunch of computers, etc. The entire network is on the, so I set my laptop for, as there was no DHCP server. Oddly enough, everything was set statically when this was set up. Part of the reason that we don’t know what everything was.

I disconnected the APC ethernet from the Hub to the switch, so only my laptop and the APC were on the hub. Then I opened up a terminal and:

$ su
# tcpdump -i eth0 -tl
This removes the time stamp (-t) and buffers the lines (-l) to keep me from missing anything.

This however produced way too much traffic. So I then used:

# tcpdump -i eth0 ip and not net -tl |grep -v
This prevented me from listening to anything on the loopback and cut out everything coming from the laptop that I had.

There was only one candidate left. So, hooking everything back up, I could then watch what the APC was doing.

# tcpdump -i eth0 src -tl

And there was the answer: the APC ( was sending a packet of information every 45 seconds or so to a host called the ET-Client, which was

So, disconnecting my laptop, and double checking that all of the wiring was proper, I then went to the ET-Client host computer and viola! Using the web browser I could connect to and was greeted by the login prompt.

Fortunately we were able to figure out the password and now have a viable means to communicate with the APC unit from the host computer within the system.

Linux – keep it simple.