Hostname Unsuitable for Printing in dhcpd logs

Some time ago I spent som time googling some strange ISC DHCPd log lines:

Oct 13 12:38:33 amuka dhcpd: DHCPREQUEST for 129.241.x.y from 00:1b:38:xx:xx:xx (Hostname Unsuitable for Printing) via 129.241.x.1
Oct 13 12:38:33 amuka dhcpd: DHCPACK on 129.241.x.y to 00:1b:38:xx:xx:xx (Hostname Unsuitable for Printing) via 129.241.x.1

Since this is a university dhcp server, it didn’t seem entirely unreasonable that some student had set this hostname in their client. However, it did appear in the server logs way to often to be only one client.

After snooping about for a while, I found some signs that this may have had something to do with dd-wrt firmware on WRT54GL access points, and moved on.

Today I had another problem with ISC dhcpd, and had to dig through the source code. I came over this code snippet in server/dhcp.c , which sort of describes the previous issue: (hm, seems like wordpress eats the indentation in the blockquotes. sorry about that.)

if (lease && lease -> client_hostname) {
if ((strlen (lease -> client_hostname) <= 64) &&
db_printable (lease -> client_hostname))
s = lease -> client_hostname;
s = “Hostname Unsuitable for Printing”;

And in db_printable() from server/db.c:

for (i = 0; s [i]; i++)
if (!isascii (s [i]) || !isprint (s [i])
|| s [i] == ‘”‘ || s [i] == ‘\\’)

isascii() is a macro defined in minires/res_init.c (hmm, strange location) and is defined as:

# define isascii(c) (!(c & 0200))

This means that all printable lower ASCII (original 127 US-ASCII) chars are allowed, but nothing else. Call your machine Haarföner, install MacOS and get your own name (with Norwegian special characters æ, ø or å) in the hostname, and the name is replaced with Hostname Unsuitable for Printing  in the logs.

What practical use this has, is still not determined.

This entry was posted in stuff and tagged , , . Bookmark the permalink.

1 Response to Hostname Unsuitable for Printing in dhcpd logs

  1. I agree this way of handling it might be cryptic, but hey, hostnames are after all only the left part before the first point of a FQDN. So it is NOT a normal setup to put ascii in a reply from hostname.

    Now the problem, IMHO is on MacOS that accepts funny hostnames with non-ascii chars, or if you want, that it uses this non-ascii string as a dhcp reply, which shouldn’t be on the RFCs…

    Also, some implementations of syslogd might not like daemons printing something that is not pure ASCII (I don’t know, I’m just guessing, knowing that a software like ISC DHCP must be used on nearly all platforms), so I guess the author of this code knows what he is doing.

    If I was you, as an administrator seeing this, I would patch DHCPd so that it doesn’t provide a DHCP IP to such Mac, violating all RFC and performing a DHCP attack!!! :)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s