On Mar 7, 2011, at 10:47 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joel Jaeggli" <joe...@bogus.com> > >> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 >> >> 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 49.48.46.49 until you get new >> firmware) > > (HP Blades apparently depended on rDNS for 49.48/16 failing hard, which > stopped happening when the block was allocated)
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 "10.1.1.1" the first 4 characters were "10.1" which is 49.48.46.49 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 49.48.46.49 though, which is probably bad. (the above is my own attempt at figuring out what was happening, but might not be 100% accurate)
