why hp bladeserver chassis have a sudden interest in thailand.


As a potentially cautionary tale for the squatting on unused pieces of
address space either in your network or applications.

drive slow (and filter 22 outgoing to until you get new


(HP Blades apparently depended on rDNS for 49.48/16 failing hard, which
stopped happening when the block was allocated)

Hey, isn't this what I was talking about a week or two ago: applications
depending on DNS not lying to them about whether things actually exist or
not? (Ok, it's a *bit* sideways, but not much...)

-- jra

For those at home scratching their heads, I ran into this before too when trying to figure out why they were making in-addr.arpa requests over and over again...

49 decimal in ASCII = "1"
48 decimal in ASCII = "0"
46 decimal in ASCII = "."
49 decimal in ASCII = "1"
or "10.1"

If you had a hard-coded IP address instead of a hostname for its management host, the logic to resolve the hostname would get confused and attempt to do a reverse-dns lookup of the first 4 characters of the ASCII representation of the hostname, and connect to that instead. So, if your management host was "" the first 4 characters were "10.1" which is if you smash the values of each character into a v4 address and try to grab a PTR record for it. If that lookup failed, it'd fall back to connecting to the IP correctly. Only after 49.48/16 was assigned and started giving out PTR records did this bug actually do anything.

It is attempting to SSH to the host at though, which is probably bad.

(the above is my own attempt at figuring out what was happening, but might not be 100% accurate)


rofl. the goddesses are indeed just.



It is going for a range of ips. We only see syn's never a response from the ips.
Netflow sampling at 1/1k results from yesterday's SSH fun:)

Countx1k ip

(coffee != sleep) & (!coffee == sleep)