$ traceroute God

Linux and the Brother HL-2270DW printer: success!

2011-05-16T18:51:00.000-04:00

This printer was remarkably easy to setup under Linux. It was something of an impulse buy after my inkjet ran out of ink... and after I clicked "Checkout" I thought to check what Google had to say about the support for Linux. There were no great success stories, so I thought I would have to fight with it for a few weeks to get it to a decent state... Surprise! It took only a few hours, of which most were me exploring the device.

I setup the printer on the network using ethernet (the wireless is nice, if I need it later... but for now it's sitting next to the router, so...) and for sanity I set it to get the same dhcp leased IP address (the lazy man's static). The Printers dialog in Fedora 14 quickly discovered the printer after I opened the Network arrow, which was really cool. I found out, via Wireshark, that it has some kind of webservice broadcast thing as well as a SNMP method of discovery... oh, and netbios. There's probably a few I'm missing... oh yes, dns-sd/avahi and LLMNR... anyway, the network support built-in to this printer really impressed me.

I actually ended up selecting IPP printers and entering the URI manually rather than choosing the automatically discovered one, which had a URI like: dnssd://Brother%20HL-2270DW%20series._ipp._tcp.local/ Entering it manually seemed to give me a few more options and even detected the toner level (well, kind of- I think the "starter" cartridge screws it up... we'll see after I print my way through it). The URI I used was: ipp://$IP/pcl_p1 and the driver I chose was "Generic PCL Laser Printer" with the Duplex option checked. And it's worked perfectly since then!! How awesome is that. I didn't even have to install any of the semi-GPLv2 software from Brother.

In short, I would recommend this printer to anyone that's looking for a full-featured (black/white and single-function) and yet not way too expensive laser printer. Especially if you can find it on sale for $79.99 like I did :-)

update your xbee firmware under linux!

2011-02-04T16:48:00.003-05:00

I just got a pair of xbee radios from Digi (http://www.digi.com/xbee/) last week, as I begin my hobby of embedded electronics, and they're very cool. I already have a ton of ideas that, given time and money, I want to work on. The only thing that bothered me was that there was no firmware update utility for Linux. Well, no more! The datasheet from Digi had the details of how to enter the bootloader and upload firmware to the xbee, and I spent the past few nights learning about serial communication and programming. The result is a small utility that can upload new firmware images to your xbee!

As of now, there are a couple of caveats (that will all eventually be fixed):

~~the device is hard-coded as /dev/ttyUSB0~~
~~you can only program an xbee currently in AT mode (you can go to API mode fine, but my utility doesn't speak API yet)~~
need to handle radios in strange states or non-default baud rates, etc.

I only have 2 radios to test on, so: FLASH AT YOUR OWN RISK! This works for me, but I'm sure that there will be situations and hardware that this will not work on (for now). That aside, the xbee bootloader seems fairly robust, and when I accidentally re-programmed the same block several hundred times, it was able to recover.

I'll edit this later after I find a place to put my code...
Edit: https://github.com/roysjosh/xbee-comm

And now, the text equivalent of a screenshot!

$ time { ./xbfwup 2270/ebl_files/XB24-ZB_2270.ebl ; }
Read 100608 byte firmware file (786 blocks).
................................................... 50
.................................................. 100
.................................................. 150
.................................................. 200
.................................................. 250
.................................................. 300
.................................................. 350
.................................................. 400
.................................................. 450
.................................................. 500
.................................................. 550
.................................................. 600
.................................................. 650
.................................................. 700
.................................................. 750
...................................
Programming complete, running uploaded firmware...

real 0m25.392s
user 0m0.023s
sys 0m0.042s

firefox, x509, Subject CN, and subjectAltNames

2010-11-18T11:26:00.000-05:00

Note to self: firefox will ignore the Subject CN if you have a DNS subjectAltName in your certificate. Sigh. /me revokes and regenerates certificates...

order is important: memset, thunderbird 3.0.1

2010-01-28T14:25:00.004-05:00

A few minutes ago, I heard that Thunderbird 3.0.1 can cause email corruption, which alarmed me, because that's what I am currently running. I investigated, and noticed that in the patch the root issue was an incorrect usage of memset... Specifically, the "size_t n[umber]" parameter, which indicates how many bytes to write, was swapped with the "int c[onstant]" parameter, indicating the byte to write. Luckily for most of these "backwards" errors, the fill-byte constant is a 0, so when it is placed in the "number of bytes to write" position, it doesn't matter that there is now a "random" number in the fill-byte constant. Unfortunately, you then end up using uninitialized (or old) data, like in this case with TB3. A google codesearch reveals just how often this problem occurs...

jwhois-4.0 and 100% CPU usage on whois lookups

2009-10-16T16:21:00.001-04:00

A few months ago I started to notice that every now and then a whois lookup would eat one of my CPUs. Running whois under strace quickly revealed something interesting:

$ strace whois $FOO

...

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET, sin_port=htons(43), sin_addr=inet_addr("149.17.192.7")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(1024, NULL, [3], NULL, {75, 0})  = 1 (out [3], left {74, 974605})
getsockopt(3, SOL_SOCKET, SO_ERROR, [-1482919303840792576], [4]) = 0
...

read(3, 0x7fffeb6b97b0, 1023)           = -1 EAGAIN (Resource temporarily unavailable)

... (repeat the above a lot, varies from run to run) ...

read(3, "NOT FOUND\n"..., 1023)         = 10
read(3, ""..., 1023)                    = 0
write(1, "[whois.publicinterestregistry.net"..., 45[whois.publicinterestregistry.net]
NOT FOUND
) = 45
exit_group(0)                           = ?

And then it would exit. So, for some reason jwhois switched from blocking sockets in v3 to non-blocking in v4. Why? I have no idea. It is, after all, only going to be dealing with one IO operation at a time (non-blocking fds are usually used when you need to poll multiple "things" at the same time).

Let's find out where this read() is via gdb:

$ gdb jwhois

...

(gdb) break getsockopt

Breakpoint 1 at 0x401c30
(gdb) run $FOO
Starting program: /usr/bin/jwhois $FOO
[Querying whois.publicinterestregistry.net]

Breakpoint 1, 0x0000003e2f0df1a0 in getsockopt () from /lib64/libc.so.6
Current language: auto; currently minimal
(gdb) clear getsockopt
Deleted breakpoint 1
(gdb) break read
Breakpoint 2 at 0x3e2f0d1470
(gdb) c
Continuing.

Breakpoint 2, 0x0000003e2f0d1470 in read () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003e2f0d1470 in read () from /lib64/libc.so.6
#1 0x000000000040c1b0 in read (__nbytes=, __buf=, __fd=)
    at /usr/include/bits/unistd.h:45
#2 whois_read (__nbytes=, __buf=, __fd=) at whois.c:127
#3 0x000000000040c316 in whois_query (wq=0x7fffffffe0d0, text=0x7fffffffe078) at whois.c:84
#4 0x000000000040bde1 in jwhois_query (wq=0x7fffffffe0d0, text=0x7fffffffe0f8) at jwhois.c:298
#5 0x000000000040c08e in main (argc=2, argv=0x7fffffffe218) at jwhois.c:181
(gdb)

Above, I decided to break on getsockopt() - it was the closest (unique) system call to the read() I wanted to examine. And now we can see that whois.c, line 127 is our culprit. I decided to stick a select() right above the offending read() in order to sleep until the socket was ready to be read, instead of busy-wait looping. Here's the patch:

diff -ur jwhois-4.0.old/src/whois.c jwhois-4.0/src/whois.c
--- jwhois-4.0.old/src/whois.c 2007-06-26 03:00:29.000000000 -0400
+++ jwhois-4.0/src/whois.c      2009-04-29 11:42:56.000000000 -0400
@@ -115,6 +115,7 @@
   unsigned int count, start_count;
   int ret;
   char data[MAXBUFSIZE];
+ fd_set rfds;

   count = 0;

@@ -124,7 +125,15 @@

   do
     {
+      FD_ZERO(&rfds);
+      FD_SET(fd, &rfds);
+      ret = select(fd + 1, &rfds, NULL, NULL, NULL);
+
+      if (ret <= 0)
+        return -1;
+
       ret = read(fd, data, MAXBUFSIZE-1);
+
       if (ret >= 0)
        {
          count += ret;

converting zmud maps to tintin++, and tintin++ with 100k rooms

2009-01-16T23:44:00.005-05:00

The past few days I've been examining the telnet clients available for linux. There isn't too much to speak of, unfortunately. Many of them aren't under active development. However, I found a new MUD client being developed called mudlet that has the potential to be pretty cool.

I ended up using tintin++, since it had a rudimentary auto-mapper which looked interesting. After playing around with it for a while, I wondered if there was a way I could use my zmud maps with tintin++. I couldn't find my wotmud maps from a long time ago, so I grabbed the ones available from map.wotmad.org. What follows is the rough steps it took to get them into a format tintin++ understood.

export zmud MDB data
regex it into something sqlite likes
throw it at sqlite
tweak some data so tintin++ can do more things (like colors) faster/easier
grab what we need from sqlite and output tintin++'s format

What you need:

mdbtools
sqlite3
DBD::SQLite
mdb2sqlite.pl
zmudconv.pl

And of course a zmud mdb file. And now...

$ perl ./mdb2sqlite.pl zmud.mdb
...
$ perl ./zmudconv.pl zmud.mdb.sqlite > tintin.map

mdb2sqlite.pl throws some errors on MetaTbl and another at the end, but they seem to be harmless. If you have a suggestion for a fix, I happily accept patches (or just guru-like advice too, I suppose).

Also, a few more things. My wotmud map had too many rooms for tintin++, so I wrote a little patch that increases the maximum (to 100k) to fix that. It seems to work for me, but YMMV.

Finally, for those of you using a distro without tintin++, but with RPM, here's a specfile for you (that uses the above patch, too). Just pull the patch into SOURCES/ first.

$ rpmbuild --sign -ba SPECS/tintin.spec

* Without the --sign if you don't have rpm set up to use gpg.

Anyway, happy MUDding!