CentOS 5.3 (mostly) released

CentOS 5.3 has been mostly released; mirrors are synced, the .iso images can be downloaded, and I'm currently over 50% done downloading both the 32-bit and 64-bit CentOS DVD image torrents:

32-bit DVD image torrent

64-bit DVD image torrent

(Note that are issues getting these torrent files, but the file is well-seeded, with about 500 seeds and peers for both torrents right now)

I should have both files downloaded this afternoon.

yum update doesn't update to CentOS 5.3 yet, but should by tomorrow this time.

Deadwood snapshot update

OK, here is my first release with logging working in Windows with Deadwood. The log is placed in log.txt; right now the log is only updated when the program is stopped, and log.txt is overwritten whenever the service is started. Also, dwood2rc errors could look a little nicer. But, it's a start; I will clean up logging tomorrow.

It's at the usual place.

ObHack 005c released

I have released ObHack 005c today:

• Bugfix: The reason why the outdoors theme occasionally had a Wolfenstein door was because there were no doors marked for the nature theme, so ObHack would just choose any door at random. Fixed (Andrew had this fix for Oblige 0.97, but it took a bit of prodding to figure out which diff was the fix)
• Minimize the use of prefabs with Wolfenstein textures in non-Wolfenstein levels
• Memory leak in RNG plugged
• FLTK updated to use FLTK-1.1.9 (which actually makes the source tarball smaller; I also don't like having the code use a developer snap of some library to compile)

It can be downloaded at samiam.org/slump.

Deadwood snapshot update: Service now correctly stops

OK, I was able to squeeze in a little bit of free time this weekend in order to get the Deadwood service to correctly stop. When the service is stopped, Deadwood now writes the cache to a file in Windows. The main advantages of having Deadwood be a service is that it automatically starts at system boot time, it doesn't need an open window while running any more, and when it is stopped, it can write the cache to a file before terminating.

Basic service functionality is now ready. I've also revised some of the documentation so it is easier for people to compile and use this program in Windows. Next:

• Set up logging when Deadwood is a service (I did some of this work yesterday, so I just need to finish this up)
• Have the code that installs and removes the service make sure the service, in fact, has been installed or removed and tell the user this
• Remove all Win32 compile-time warnings
• Release Deadwood 2.2.01 (non-stable release of Deadwood), both as source code and as a Win32 binary

Today's snapshot can be downloaded at the usual place.

Deadwood snapshot update: A working Windows service

OK, I've made some progress with Deadwood today. It does work as a Windows service, but its service code has a number of kinks I need to iron out:

• The service can be started but not stopped without using the task manager to kill the process
• The service has issues with removing the service from the service registry
• There is no proper logging of Deadwood
• I have some basic documentation, but really need to properly document this service

I hope to have time to clean this up this weekend, but I'm going to be pretty busy. We'll see. In the meantime, people can download the Deadwood developer's snapshot here

No Deadwood update today

I had every intention of working some more on the service code for Deadwood today; however this morning, as I was setting up my computer, a co-worker came to me with a huge spreadsheet with over 8,000 entries. She told me she needed a number used for Mexican ID purposes calculated for all of these entries.

There's a fairly easy way of calculating a reasonable approximation of this number if you know their full name, their gender, and in which state they were born. Well, the spreadsheet this co-worker gave me only had their full name, and the name of the city (not state) they were born in.

So, not only did I have to figure out how to calculate this number, I also spent the day downloading a list of all notable cities in Mexico (cities with zip codes) and which state they are in, and another list of names and which gender usually has a given name. I haven't really touched Perl for a few years, but this kind of data consolidation and merging is perfect for Perl, so I wrote a series of shell, Perl, and awk scripts to consolidate this data.

When everything was said and done, I was able to reasonably accurately calculate the requested numbers for about 40% of the data I got. I gave this data to the co-worker this afternoon and told her I would work more on this next week. As you can imagine, all of this Linux scripting left me mentally exhausted by the end of the day.

Needless to say, I wasn't able to work on Deadwood. I will see if I can work on it tomorrow. In the meantime, I did post a snapshot of Deadwood yesterday with a copy of the service code I have been working on this last week here, but it hasn't been integrated in to Deadwood yet.

I've got a working Windows service running

I can't say I've mastered the black art of making a Windows service, but I now have a simple working Windows service that compiles in my MinGW-3.1.0/MSYS-1.0.10 setup. The "service" version of MicroDNS can be downloaded here (that's a link to click on) or looked at by clicking on this link.

MicroDNS is a tiny DNS server that does only one thing: It always sends a given IPv4 IP to any and all queries sent to the server.

The ip the Windows service version of this program sends is 10.11.12.13, and the service binds to the IP 127.0.0.1

This program is a Windows service; I would like to thank Steve Friedl who put a public domain simple Windows service on his web site at unixwiz.net; his public domain code made it possible for me to write the Win32 service code.

To compile:
gcc -O3 -DMINGW -o microdns-service microdns-service.c -lwsock32

After compiling, one needs to install this service:

microdns-service.exe --install

Then one can start the service:

net start MicroDNS

(It can also be started from Control Panel -> Administrative tools -> Services; look for the "MicroDNS server" service)

To stop the service:

net stop MicroDNS

(Or from the Services control panel)

To remove the service:
microdns-service.exe --remove

This program has been verified to compile and run in a MinGW-3.1.0-1 + MSYS-1.0.10 environment; for details on how to set up this environment in Windows, go to this page:

http://maradns.blogspot.com/2009/03/mingw-310-1-last-real-mingw-release.html

Now that I have the basics of Windows service programming down, the next step is to make Deadwood a proper Windows service.

MaraDNS snapshot update

I have made a couple of changes to MaraDNS today:

• I have removed deadwood-1 and updated deadwood-2 to be deadwood-2.1.01 in the MaraDNS tree; this syncs the MaraDNS and Deadwood releases. This saves me from having to maintain two Deadwood trees (Deadwood-1's TCP code didn't work). One of my plans for Deadwood-2.3 is to have it be modular, so people who don't want caching can remove all caching code from Deadwood-2
• Since I got yet another request for having a "all DNS queries return the same IP" setup, I have added microdns to the tools/misc directory of MaraDNS

The snapshot can be downloaded here.

MaraDNS snapshot update

I have updated the MaraDNS contact page to clarify that I no longer provide unpaid support for MaraDNS. Since MaraDNS has an internal copy of the main pages on the MaraDNS.org webpage, this resulted in the corresponding update for MaraDNS, which can be looked at here

---

I am slowly but surely learning the dark art of Windows service programming. I will post a simple Windows service program once I get this figured out.

ObHack 005a released

One thing that has always annoyed me a bit about ObHack is the fact the library for the underlying random number generator only allows a 32-bit seed to be used.

I have fixed this. Instead of using the Mersenne twister as a random number generator, ObHack now uses the 32-bit version of RadioGatún as the RNG. This allows us to take advantage of the fact that RadioGatún allows an arbitrarily long input as its "seed" and can output a arbitrarily long stream.

Since RadioGatún is (as far as this academic cryptographic community knows) a secure stream cipher, its output is indistinguishable from random noise.

I have changed the relevant parts of the LUA scripts to seed the random number generator with a string instead of a number, and have changed the GUI dialog code to allow any string up to 16 characters long to be inputted as the RNG seed.

If a seed longer than 16 characters is desired, this can be done by invoking ObHack from the command line. To do this:

• Open up the ObHack gui from the directory containing ObHack
• Configure, in the GUI, the type of game you want ObHack to make (level size, number of monsters, game type, number of maps to make, etc.)
• Leave the GUI without making a level
• Now, invoke ObHack from the command line with the first command line argument the seed of the map you want to make that starts with a number. For example, to use the seed '12345-long-ObHack-seed.wad' invoke ObHack as ObHack 12345-long-ObHack-seed.wad. It will generate a .wad file with both the name and seed '12345-long-ObHack-seed.wad' (yes, the .wad extension will be part of the RNG seed).
• This can be done repeatedly from a script if you have a few DVD-R blanks you want to fill up or what not
• Did I make it clear that a map generated from the command line must start with a number?

Note that there is a minor bug in ObHack: When I wrote the code to implement the new RNG last night, I neglected to free the memory used by the old seed when re-seeding the RNG; this means the program leaks 240 bytes of memory for every level generated by ObHack in a megawad; when making a Heretic megawad (55 levels), this leaks 13200 bytes of memory. Since it's rare to generate more than one wad file each time one invokes ObHack (following the above steps to repeatably invoke ObHack with a script restarts ObHack every time we make a .wad), so we only leak up to 13200 bytes, this isn't a serious enough bug for me to make a new release of ObHack to fix.

ObHack 005a can be downloaded at samiam.org/slump. Here is the Doomworld thread I use to announce new releases of Obhack there.

NanoRG32: RadioGatun 32 in 877 bytes of C

RadioGatun 32 in only 877 bytes of c:

/*Placed in the public domain by Sam Trenholme*/
#include <stdint.h>
#include <stdio.h>
#define p uint32_t
#define f(a) for(c=0;c<a;c++)
#define n f(3){b[c*13]^=s[c];a[16+c]^=s[c];}k(a,b
k(p *a,p *b){p A[19],x,y,r,q[3],c,i;f(3){q[c]=b[c
*13+12];}for(i=12;i;i--){f(3){b[c*13+i]=b[c*13+i-
1];}}f(3){b[c*13]=q[c];}f(12){i=c+1+((c%3)*13);b[
i]^=a[c+1];}f(19){y=(c*7)%19;r=((c*c+c)/2)%32;x=a
[y]^(a[(y+1)%19]|(~a[(y+2)%19]));A[c]=(x>>r)|(x<<
(32-r));}f(19){a[c]=A[c]^A[(c+1)%19]^A[(c+4)%19];
}a[0]^=1;f(3){a[c+13]^=q[c];}}l(p *a,p *b,char *v
){p s[3],q,c,r,x,d=0;for(;;){f(3){s[c]=0;}for(r=0
;r<3;r++){for(q=0;q<4;q++){if(!(x=*v&255)){d=x=1;
}v++;s[r]|=x<<(q*8);if(d){n);return;}}}n);}}main(
int j,char **h){p a[39],b[39],c,e,g;if(j==2){f(39
){a[c]=b[c]=0;}l(a,b,h[1]);f(16){k(a,b);}f(4){k(a
,b);for(j=1;j<3;++j){g=a[j];for(e=4;e;e--){printf
("%02x",g&255);g>>=8;}}}printf("\n");}}

To run this program, compile it with the name NanoRG32; the program will output the Radio Gatun 32 hash of the first argument given to the program. For example, to get the Radio Gatun 32 hash of "123456789012345678901", run this program as NanoRG32 123456789012345678901 and you should get a hash starting with 381957046bec1dfc08eaa0

MinGW 3.1.0-1: The last real MinGW release

Once upon a time, MinGW (a free *NIX-like developing environment for Windows that allows one to make native Windows binaries using a Linux-like environment) was very simple to install:

• Download MinGW-3.1.0-1.exe and MSYS-1.0.10.exe
• Double click on MinGW-3.1.0-1.exe, yes, "I accept", yes, yes, finished
• Double click on MSYS-1.0.10.exe, yes, "I accept", yes, yes
• A terminal window opens; usually "y" then enter so MSYS can see MinGW
• Uncheck the README and other file then click on "Finished"

Once this is done, you have a blue "M" on your desktop, which gives you a full *NIX development environment.

It's really easy to use if you're familiar with *NIX development. First, use an editor and make a file named hello.c that looks like main(){printf("Hello, world!\n");, then compile the program with gcc -o hello hello.c.

OK, some notes that, in typical open-source fashion, the MinGW developers never bothered to document. To get out of the *NIX-looking "jail" and access the full filesystem, go to a directory with a name like "/c" (the C drive), "/d" (the D drive), and so on. Note that, if you insert a USB stick after starting the msys command prompt, you will need to close the window and reopen the window before you can access the drive letter for the USB stick or what not.

The "jail" where you access files is usually "c:\msys\1.0" and you start in a directory with a name like "c:\msys\1.0\home\user" where "user" is your username in Windows.

The window with the terminal prompt is able to copy and paste to and from other Windows applications, but in a very *NIX-like way: You simply highlight something with your mouse to copy it to Windows' clipboard; to paste something from the clipboard in to the terminal window, simply click on either the middle button of your 3-button mouse (this is the wheel if you're using a wheel mouse) or both the left and right buttons at the same time (if you're using a 2-button mouse), and whatever is in the Windows clipboard will be pasted as if you typed it at the terminal window.

Well, ever since MinGW 3.1.0-1 and MSYS-1.0.10, the MinGW developers decided to make the install process more complicated, requiring downloading one program which in turn downloads whatever the MinGW developers decide is the current version of MinGW today (which makes it difficult to have a stable development environment). Fortunately, one can still readily download both MinGW-3.1.0-1 and MSYS-1.0.10; the total download size for these two programs is under 20 megs. Here is a Sourceforge link to download MinGW 3.1.0-1 (The MinGW developers have gone out of their way to hide this link), and here is MSYS-1.0.10.exe. For people wanting to verify these packages, here are the MD5 sums for these programs:

da686e2c7b283385ef79d7b75afb609c MSYS-1.0.10.exe
3784d99307566bd0a5f3790abdd35ee1 MinGW-3.1.0-1.exe

Here are the SHA1 sums:

510fcfa923833073bc55302913739e25b909e66a MSYS-1.0.10.exe
9c3d53eab502230eab01548f2e73e450539971b1 MinGW-3.1.0-1.exe

And here are the Radio Gatun 32 sums:

1550c17dcf05c9035a4d73e7bf7cc4165711006a57d00818282a562fca69e806 ./MinGW-3.1.0-1.exe
dff74bc62f2df11becc0b550e952ce3e2f48de092c32cb50e1290e4a38cadc33 ./MSYS-1.0.10.exe

Radio Gatun cryptanalysis (NOT broken) ; Deadwood minor update

Over two years have passed since RadioGatún was published; there finally has been some cryptanalysis of RadioGatún. In the first attack (PDF file), Dmitry Khovratovich and Alex Biryukov were able to attack RadioGatún with a complexity of 2^576 for the 32-bit version of RadioGatún. This attack is clearly not practical, and is only slightly less complex than the claimed security for RadioGatún32, 2^608.

Thomas Fuhr and Thomas Peyrin have a more successful attack; they claim to be able to break RG32 with a complexity of 2^352 (and actually break the 2-bit version of Radio Gatún in their paper). Again, the attack is not practical, but is significantly less complex that RG32's security claim of 2^608. Even if this attack can be extended to the 32-bit version of RadioGatún, RG32 can still be used to make secure 512-bit hashes (a birthday attack on a 512-bit hash has a complexity of 2^256). I personally use it for 256-bit hashes and feel that there will not be any cryptanalysis that makes a collision attack for RG32 easier than 2^128 (and probably no attack easier than 2^256).

There has been no cryptanalysis against using RG32 as a stream cipher (like I do in Deadwood), and RadioGatún's close relative, Panama, has been around since the late 1990s and never has been broken when used as a stream cipher.

---

I am working on making Deadwood a bona fide Windows service. The first step of this work, porting MicroDNS to Windows (so I have a very simple server to make a service out of), has been done and can be downloaded as microdns-simple.c. Compile this program as gcc -DMINGW -o microdns-simple microdns-simple.c -lwsock32 on a Windows system with MinGW.

Deadwood snapshot update: DwMain and DwTcp are now a single combined binary

In today's update to Deadwood, I have made DwMain and DwTcp a single combined binary. This combined binary is under 28k in size (when compiled with -Os and stripped on an x86 32-bit platform) and supports both DNS-over-UDP and has basic support for DNS-over-TCP. I have verified this combined binary compiles and works in both CentOS 5 and in Windows XP.

I have removed the DwTcp man page, and have noted in the DwMain man page that DwTcp is now nothing more than a symbolic link to DwMain (DwMain checks the name it is invoked as, and runs as a DNS-over-TCP daemon when invoked as "DwTcp").

In addition, I have added a security section to the DwMain man page that discusses security best practices for DwMain.

My next Deadwood task (after getting rid of the one or two compile-time-warnings when compiling in Windows) is to make DwMain a bona fide Windows service.

A couple months ago, when dealing with a problem with time slew in my VmWare virtual machine (which I subsequently solved by having VMware tools on the guest), I found a very simple public domain Windows service (complete with source code) that acts a rdate server. I will use code from this program to make DwMain a Windows service. I estimate I will need a couple of weeks to make this code happen; CentOS 5.3 will probably be released as I'm working on improving the Windows port.

It can be downloaded at maradns.org/deadwood/snap

MicroDNS and Deadwood updates

The MicroDNS code I posted last week had some bugs that made it not work (when I changed the code to use sub-functions instead of a single main() function, I did not do all of the needed changes); when working on Deadwood, I discovered and fixed these bugs today, and MicroDNS now works. The corrected version of MicroDNS can be downloaded here

I have added another test to Deadwood: The "Roy Arends" test. This test make sure that the Deadwood DNS server doesn't answer DNS answers (otherwise the server would be vulnerable to a denial-of-service attack). Deadwood passed the test with flying colors. Deadwood can be looked at here, and today's snapshot (20090317) can be downloaded here.

- Sam

Proposed possible configurations for the next Deadwood release

For testing reasons, and to minimize bugs, I am only going to allow seven different configurations in the next Deadwood release that allow the user of Deadwood to balance features against code side. Here are the configurations I plan on having:

1. non-cached, no-parser UDP
2. non-cached, parser UDP
3. non-cached, parser UDP + TCP (Deadwood 1.0 replacement)
4. Partial cache (no reading and writing to disk, no resurrections), parser UDP only
5. Partial cache (no reading and writing to disk, resurrections), parser UDP + TCP
6. Full cache, parser, UDP only
7. Full cache, parser, UDP + TCP

This balances the need for Deadwood users to fine-tune the size of the Deadwood binary against the need to limit possible configurations so testing and bug-fixing is possible.

Roadmap for Deadwood 2.2 and 2.3

Now that Deadwood 2.1 is out, and is declared stable, I am going to start work later on this week on the Deadwood 2.2 code which will eventually become the stable 2.3 branch of Deadwood. Here is my tentative roadmap for Deadwood 2.2:

• Make DwMain (the UDP client) and DwTcp (the TCP client) a single combined binary.
• Make Deadwood a bona fide Windows service, with support for proper shutdown (read: Writing the cache to disk when shutting down), startup (not needing a terminal window open to run), etc.
• Making the code more modular; in other words, making it possible to, for example, compile and run Deadwood without TCP support or without the ability to read and write the cache to a file. This allows people to make Deadwood a smaller binary if they don't want all of Deadwood's features.

Once these three features are implemented and tested, I plan on releasing Deadwood 2.3.

Windows FAT patent rant; NanoDNS bug

As had been widely reported in the press, Microsoft is suing someone for using the FAT32 filesystem without licensing. This is downright anti-competitive monopolistic behavior and behavior Microsoft should not be allowed to do without repercussions.

The problem is this: For a device, such as a USB stick, digital camera, GPS unit, or whatever to connect to and work with Microsoft Windows, the device in question must use a filesystem Microsoft Windows supports, since Microsoft has a monopoly position on the desktop. Unfortunately, Microsoft has a patent for any and all filesystems they support, so to make a device you are forced to use a patented filesystem and get a patent license from Microsoft.

It used to be possible to create a driver to give Microsoft support for another filesystem, such as ext2 in pre-Vista versions of the operating system. Indeed, I use the open-source ext2fsd on my XP system to have the majority of the data on my hard disk stored using Linux's second extended filesystem (the native filesystem for Linux throughout the 1990s and early 2000s; the updates to ext2 are mostly ext2-compatible, and Linux still has 100% ext2 support). So, this stops the majority of my data from being stored using a patented filesystem.

Unfortunately, Windows Vista no longer supports third-party filesystems. Let me take that back. In theory, Windows supports non-patented filesystems, but you have to get rid of the UAC (the Visty thingy that makes sure a virus doesn't do something it shouldn't do without your permission) to give Vista support for non-patented filesystems (see this page for a description of the issue).

This reminds me of when Microsoft made it so Windows 3 would not work with DrDos because they wanted to stop people from using non-Microsoft operating systems for their computer. Microsoft, with Windows Vista, has broken the ability to use a non-patented filesystem (that is more modern than having 8+3 filenames) with a normal install of their OS.

Since Microsoft has made a technical solution impossible, the only solution is a legal solution. One solution is to invalidate the FAT32 patent, because everything it patents was done before (the idea of using meta-information to map long file names to short file names was done with Rock Ridge which was published before Microsoft filed for the FAT32 patent). Another solution is to sue Microsoft for engaging in antitrust behavior, since it can be shown, with Vista, that Microsoft removed compatibility for non-patented filesystems, forcing people to license Microsoft's patents, not because the patents are novel, but because the patented filesystems must be used for interoperability purposes.

---

The copy of NanoDNS I posted yesterday has a bug; it will not work on systems where int is not 32 bits in size. No, I will not fix this bug; people can just use MicroDNS if they need to run a small DNS server on a system that is 64-bit or whatever.

MicroDNS and NanoDNS

I have been posting a small program for real programmers that is a simple DNS server that always returns the same IP reply to any query sent. I also have a version of this program for wanna-be programmers; this program is properly indented, has comments, descriptive variable names, and other things real programmers prefer to do without. It even gives usage information if incorrectly invoked. It is available at samiam.org/software/microdns.html

However, if the comments and coding style of MicroDNS bothers you, I have managed to get rid of even more bloat from NanoDNS, and have the updated program posted here:

/*Placed in the public domain by Sam Trenholme*/
#include <arpa/inet.h>
#include <string.h>
#define Z struct sockaddr
#define Y sizeof(d)
int main(int a,char **b){int i;char q[512],p[17
]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a>1){a=
socket(AF_INET,SOCK_DGRAM,0);struct sockaddr_in 
d;bzero(&d,Y);d.sin_port=htons(53);*((int *)(p+
12))=inet_addr(b[1]);d.sin_family=AF_INET;bind(
a,(Z*)&d,Y);socklen_t f=511;for(;;){i=recvfrom(
a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0){q[7]++;q[
2]|=128;memcpy(q+i,p,16);sendto(a,q,i+16,0,(Z*)
&d,Y);}}}return 0;}

The world's smallest DNS server made smaller

After posting the tiny DNS server yesterday, I realized that this code was somewhat bloated. Going over the code this morning, I have managed to remove some bloat and have made the DNS server 17% smaller, resulting in this compact and efficient DNS server:

/*Placed in the public domain by Sam Trenholme*/
#include <arpa/inet.h>
#include <string.h>
#define Z struct sockaddr
#define Y sizeof(d)
int main(int a,char **b){long int i;char q[512],p
[17]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";socklen_t
f=511;if(a>1){i=htonl(inet_addr(b[1]));p[15]=255&
i;struct sockaddr_in d;bzero(&d,Y);p[14]=(65280&i
)>>8;a=socket(AF_INET,SOCK_DGRAM,0);d.sin_family=
AF_INET;d.sin_port=htons(53);p[13]=(0xff0000&i)>>
16;p[12]=i>>24;bind(a,(Z*)&d,Y);for(;;){if(11<(i=
recvfrom(a,q,255,0,(Z*)&d,&f))&&q[2]>=0){q[7]++;q
[2]|=128;memcpy(q+i,p,16);sendto(a,q,i+16,0,(Z*)&
d,Y);}}}}

Note that, if an argument for the IP to give to DNS queries is not given, the program exits with a semi-random exit code instead of giving the IP 0.0.0.0 to all queries (I did it this way to remove some blot from the code), and that there is now a single compile-time warning when compiled with -Wall as a result; if this bothers you, you can place 10 bytes of bloat in the form of return 0; at the end of the program (before the final }).

Note also that this program violates Deadwood coding style standards because, among other reasons, a variable is declared after other actions are performed.

Usage is the same as the more bloated form of this program that I posted yesterday; compile the program and give it the name nanodns and run the program as something like nanodns 192.168.146.134 to give, say, the IP 192.168.146.134 as a reply to any DNS query sent on port 53 of any IP the machine has (and can bind to) when the program is started. Yes, I know, real programmers do not need documentation and can figure all this out just by looking at the above code. I apologize for making concessions for wanna-be programmers (I also have a social life, use Windows, and even have a girlfriend [1]).

OK, OK, tomorrow, I will talk about MicroDNS, which is a large, bloated form of the above program, including such unneeded bloat like comments, indentation, documentation, descriptive variable names, usage information if invoked incorrectly, and other bloat that real programmers do not need. In addition, MicroDNS has some bloat because you can optionally specify which IP the server binds to (if not specified, it binds to all IPs).

- Sam

[1] Took me nearly a year of work to find one; this is why Deadwood 2.1.01 was released in 2009 instead of 2008.

The world's smallest usable DNS server

Sometimes, I get requests for MaraDNS to be able to always return a given IP for any query. While MaraDNS is able to do this (with csv2_default_zonefile), it is actually possible to have a much more compact DNS server do the same thing.

I am posting today in this blog a tiny DNS server that does just that. This DNS server always sends the same IP for any and all DNS queries it receives. This IP defaults to "0.0.0.0", but can be changed by supplying a different IP on the command line. I call this program "nanodns", and its source code is as follows:

/*Placed in the public domain by Sam Trenholme*/
#include <arpa/inet.h>
#include <string.h>
#include <stdint.h>
#define Z struct sockaddr
int main(int a,char **b){struct sockaddr_in d;
char q[512];socklen_t f=sizeof(q);uint32_t i=0;
char p[17]="\xc0\x0c\0\x01\0\x01\0\0\0\0\0\x04";
int s;if(a==2){i = inet_addr(b[1]);}i = htonl(i);
p[12]=i>>24;p[13]=(i&0xff0000)>>16;p[14]=(i&65280
)>>8;p[15]=i&255;s=socket(AF_INET,SOCK_DGRAM,0);
memset(&d,0,sizeof(d));d.sin_family = AF_INET;
d.sin_port = htons(53);bind(s,(Z *)&d,sizeof(d));
for(;;){i=recvfrom(s,q,255,0,(Z *)&d,&f);if(i<12
||(q[2]&128)){continue;}q[2]|=128;q[7]++;for(a=0;
a<16;a++) {q[i+a]=p[a];}sendto(s,q,i+16,0,(Z *)&d
,sizeof(Z));}}

To use this program, compile the above source and give it the name "nanodns". To specify the IP you want returned, specify this as the one argument to the program. For example, to always give the IP "192.168.146.132" to any DNS query received by the server, run this program as nanodns 192.168.146.132

This program binds to all addresses the machine running this program has on port 53 (the DNS port); I have a larger (and more readable) version of this program that allows one to change the IP one can bind to which I will put on my webpage and talk about tomorrow.

I will also discuss Deadwood's coding style in future installments of this blog. For example, the above code does not conform to Deadwood's coding style standards (but fits in this blog).

Deadwood and MaraDNS snapshot update

Yesterday, when I released Deadwood 2.1.01, there were still some non-memory-leak errors reported by Valgrind. I found the sounce of these warnings: One of the sources of entropy I use for the random number generator is by reading uninitialized memory; this might give the RNG reasonable entropy when run on Windows systems where the administrator neglects to change the contents of secret.txt.

Well, Valgrind doesn't like seeing uninitialized memory read and used like this and complains loudly. To resolve this issue, I have added a new compile-time define (-DVALGRIND_NOERRORS) that allows the program to be run in Valgrind without getting nasty errors about using uninitialized data. This removes all Valgrind run-time errors.

In addition, I have updated the MaraDNS source code to always use the make.download.embed script to make the download page for MaraDNS, which makes updating this page for new versions of MaraDNS much easier; in addition, I have updated the security page to point out that MaraDNS' hasnt had any reported security problems since August 29, 2007 and the download page to have a pointer to Deadwood, now that Deadwood is stable.

When I say Deadwood is stable, I am not so pretentious to say Deadwood has no bugs. What I mean is that this release of Deadwood has been extensively tested (both with over a year of real-time use and with a SQA battery I have spent the last month setting up) and appears to be ready for general release. This also means that I will fork this codebase; the Deadwood-2.1 codebase is a codebase that I will add no features too, and with which the only changes will be bug fixes.

For example, the -DVALGRIND_NOERRORS change is one that will not be put in the Deadwood 2.1 branch, since this is a feature request (being able to look squeaky clean in Valgrind) and not a bug fix. I will be very conservative about what changes go in to this code, since bugfixes can sometimes introduce new bugs; see, for example, what happened when I worked on fixing the "Google problem", for example; that bug fix introduced two new bugs I had to fix in turn.

I will give Deadwood a rest for a couple of weeks, to make sure the bugs are reasonably ironed out, then will work on making the Deadwood code more modular for embedded systems, starting by making DwMain (the UDP client) and DwTcp (the TCP client) a single combined binary.

The Deadwood snapshot can be downloaded at maradns.org/deadwood/snap and the MaraDNS snapshot can be downloaded at maradns.org/download/1.3/snap.

First Deadwood stable release (2.1.01)

Well, the changes to made Valgrind not see any memory leaks in Deadwood were pretty minor; I implemented these changes this morning and added a SQA test to make sure Valgrind doesn't see the program leaking memory in the future.

So, yes, I was able to make a stable release of Deadwood today. I have already released it and it's available at http://www.maradns.org/deadwood.

Now, I'm going to make a Windows binary of Deadwood 2.1.01, and put a pointer to Deadwood on the MaraDNS web page.

- Sam

Update: A Windows 32-bit binary of Deadwood 2.1.01 is available; it's in the same location with the file name Deadwood-2-1-01-win32.zip. Note that this binary doesn't support writing the cache to disk (Windows doesn't use *NIX signal handling), but is otherwise as functional as the *NIX version of Deadwood.

Deadwood not quite ready for stable release

Tonight, I ran Deadwood through Valgrind to make sure there weren't any issues with the code. Alas, Valgrind found some issues, so I need to clean up the code so Valgrind is happy before 2.1.01 is released. This will probably only take a few days and I should have 2.1.01 released later on this week.

- Sam

Deadwood is almost ready for a stable release

The first stable release of Deadwood is almost ready! I have finished up all of the SQA tests for Deadwood and everything works. I only found one bug during all of my testing (the issue with hashing); everything works as described and I will declare this stable early next week.

I will not have time to release it this weekend because I'll be doing some personal engagements.

This almost-ready-for-release version of Deadwood can be downloaded the usual place (that's a link, guys)

From the changelog:

• resurrections test updated to verify behavior changes when resurrections is off compared to being on.
• hash_magic_number modified again to test in a consistent and automated manner
• basic_ipv6_test slightly revised and now run as part of do.tests
• SQA test for handling the case of one upstream DNS server being down; yes Deadwood will still happily process queries (albeit more slowly)
• SQA test for making sure the name and the ID agree added; passed
• SQA test to make sure CNAME chains work and we use the lowest TTL; passed
• dwood2rc parser documentation updated since the parser can actually have up to 51 states.

Deadwood snapshot; I've wiped Linux from my hard disk

I have uploaded a new snapshot of Deadwood today; this snapshot has a working test for the resurrections parameter and resurrections appear to be working without problem.

The hash_magic_number has some issues with being automated; I will work on revising the test so we can have this be one of the automated tests; it's stopping all of the automated tests from working.

It looks like Deadwood 2.1.01 will be released next week sometime. In the meantime, snapshots can be downloaded at maradns.org/deadwood

---

Last night, I installed the Alpha-test version Fedora 11. Like Ubuntu, it has a Gnome interface; the only thing different is the artwork and the terminal is hidden under "system tools". The first thing I did was try and install VMware player; it was not possible to install it.

So, this morning I reformatted both my Ubuntu and Fedora 11 partitions and used my Windows XP install disk to wipe GRUB from the bootloader. It's a relief, since things now just work and it's not one bug after another bug. The only Linux I have right now is CentOS 5.2 in a VMware virtual machine for MaraDNS/Deadwood development.

Now, I don't know how many of the bugs were caused by VMware and how many were caused by Linux. My issue is this: The Linux developers need to stop fussing around and make a stable API. Or as another Linux developer put it: Please stop wasting everyone's time with your API changes. Until the Kernel developers can get some discipline and settle down on a stable driver ABI and API, I don't see much point using any version of Linux besides RHEL/CentOS (which is stable but often lacks drivers; thankfully it appears all the drivers for my hardware will be supported whenever CentOS 5.3 comes out).

Deadwood snapshot update

I have made quite a bit of progress with Deadwood today. First of all, I have taken the meta-script that runs all of the tests and updated it to make sure we're correctly off of a MaraDNS directory to run the tests. The script then compiles MaraDNS and Deadwood before running the tests; this is just one less step needed to set up the SQA regressions.

It then runs all of the tests. Next, it recompiles Deadwood to correctly run the hash_magic_number test, and runs that test (which I have revised to be a test one can automate).

Finally, the test cleans up after itself, removing the compiled Deadwood and MaraDNS files.

In addition, I have added a test for the num_retries parameter; to run this test, I took a simple DNS-over-UDP server written for one of MaraDNS' sqa regressions, and modified the server to be a DNS server that always gives the IP "10.11.12.13" to any DNS query it receives (echoing the query ID and marking the answer as an answer), but only answers one in three queries.

The only parameters I need to test now is resurrections; in addition, I have three other tests I want to make before releasing Deadwood 2.1.01:

• A test to make sure we can still resolve all queries when one of the upstream servers is non-responsive.
• Revive the ipv6 test and make sure this test works and can run on CentOS 5
• Make sure both the name and the ID agree for incoming DNS queries.

Deadwood can be downloaded at the usual place

---

OS News had an interesting pointer to an interview with Steve Bourne, the writer of the original sh that *NIX systems have. This inspired me to make a very small almost-featureless *NIX shell called Yet another shell, which compiles in to a binary under 4k in size when compiled with -Os and stripped.

Very basic, but this might become something the Busybox project ends up wanting to have; they want to have it so one can very easily customize the features one wants in their /bin/sh, all the way down to what Yash currently is up to something that is a fully POSIX-compatible shell with arrow history and full tab expansion.

Deadwood snapshot update; Deadwood todo

I have released a new snapshot of Deadwood today:

• Test added for hash_magic_number (needs custom compile of Deadwood to run, though)
• Test added for recurse_min_bind_port and recurse_number_ports
• DwMain.txt and DwTcp.txt files munged; fixed.

The only dwood2rc parameters I have to test now are num_retries and resurrections.

I will also revise the metascript that runs all of the tests to make sure we're in the MaraDNS directory and that MaraDNS is compiled; in addition, I need to make custom compiles of Deadwood for the ipv6 test and the hash_magic_number test; I want to have the script make these custom compiles so that we can have a simple one-script solution to giving Deadwood a complete tests (for the ipv6 test, I also need to make sure MaraDNS with authonly is compiled).

Once all of the tests are done, I will release Deadwood-2.1.01; this will be a stable branch of Deadwood. I will make bug fixes to this branch of Deadwood and take responsibility for any bugs this branch may have.

Once Deadwood-2.1.01 is released, I will try to make Deadwood part of Busybox.

Deadwood snapshot update

As I was working on figuring out why the maximum_cache_elements test was not working, eyeballing the DwHash.c file, I realized that the program that makes a compressed "hash" of a string only used the first four bytes and the length of the string to determine the hash. I have fixed this bug, and will make tests to make sure this code is OK.

I have also fixed the maximum_cache_elements test (it was the test that was configured wrong, not a bug in the Deadwood program), and added a basic man page for DwTcp.

It can be downloaded at the usual place, maradns.org/deadwood.

---

Well, I found a bug in the Windows version of VMware player that the Linux player doesn't have. It would seem that any attempt to use my webcam in the guest OS when Windows is the host causes VMware to crash (core dump, I have to turn on the guest OS again, etc). The exact same webcam works with the exact same virtual machine when 64-bit Linux is the host.

Go figure. I will see if VMware 2.0 (instead of 2.5) has this issue; probably. Most likely, I will have to just install Skype and the webcam driver in my Windows XP host OS so I can have videochats with my girlfriend, family, and friends on Skype.

Deadwood snapshot update: Looks like I found a bug

Well, after doing a whole bunch of SQA testing, it looks like I have finally found a bug.

It looks like Deadwood isn't caching every single element like it should.

I discovered this when making sure maximum_cache_elements does the right thing.

I will investigate this bug and keep readers posted here. People can see the work I have been doing at the usual place

Update: The issue was with the test, not Deadwood; fixed and there will be a fixed Deadwood update tomorrow

---

I stand corrected.

I mentioned that the Brasero CD/DVD burning program doesn't correctly make records so Windows can see long file names on burned disks. This is incorrect; the bug is actually that there's something strange about Brasero-burned disks that make it so VMware player doesn't always see the long file names on these disks.

I will investigate and report, but this looks like a VMware player bug, not a Brasero bug.