dirty python network graphite hacks

I’ve been pushing historical temperature data for Vancouver into a local graphite instance using python. While pushing the data, I received this error:
socket.error: [Errno 99] Cannot assign requested address
This was strange, as I had been using the address in the loop many, many, MANY times before hitting this error. A little more sleuthing uncovered a ton of connections in the TIME_WAIT state. Around 26,000 open sockets was where I couldn’t open any more.

This little gem, was the fix:
sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER,struct.pack('ii', 1, 0))
sock.close()

Normally, after cleanly closing the connecting in python, the system will still hold the connection open for a minute or two in the TIME_WAIT state. This was causing port exhaustion. The above lines told python to send a RST (reset) which will immediately drop the connection.

Graphite complains about the reset, but does log the data.
Connection to the other side was lost in a non-clean fashion.
Perhaps, not the most elegant solution, but it served my purpose.

Bogons?

The other day, while wandering through dhcpd logs, I spied a message similar this one.
hostname arpwatch: bogon x.x.x.x 0:0:0:0:0:0
Bogons? What the heck is this about? A little Google-fu popped this post up from a OpenBSD mailing list: http://www.monkey.org/openbsd/archive/ports/0012/msg00098.html

Along with pointing out this was just a message about an invalid IP address, it stated “Others have already pointed out that ‘bogon’ means a particle of bogosity.”

Bogosity, eh? A little more Google I found this in the beloved Hacker’s Jargon File: http://www.catb.org/jargon/html/B/bogon.html

Which, of course, got me thinking about Vogons and how it’s probably been too long since I last read the Hitchhiker’s Guide to the Galaxy.

Now, what was I doing, again?