Snow

I had planned to go caching today, but the snow put paid to that idea. It's not that an inch of snow is a big problem ... unless you're caching on a bike. A) you can't see the ground you're riding over, which could be perilous and B) the caches can be invisible under a layer of snow.

So instead, I did some work in the Data Center. First, I've set up a new workstation there. My brother-in-law donated his old computer - I didn't even look at it for a few weeks, assuming it would be an old clunker, but when I did, I was very surprised. It's a Dell Inspirion, a 4-core 2.4 ghz AMD processor with a brand name I don't remember; fantasticon or something. 8gb of memory, 1tb of hard disk, and a DVI video interface. Fortunately, I have a DVI-to-VGA converter that I'm using until I can get a DVI cable. There's no PS/2 keyboard or mouse port, so I'm using a USB mouse, and one of my old IBM AT keyboards with a PS/2 to USB converter. I installed Fedora core 20, and it runs like the wind! I tried it on 1920 by 1200 pixels, and it worked, but the display was very twitchy. At first, I put it down to the age of the monitor, but then I had a thought, and tried it n 1920 by 1080, and that works very well.

I'm still working on the pix, and what I'm trying to do now, is connect up a computer that will be on the outside interface, to check that access to the dmz and inside works. So I set up a computer with the ip address 9.9.9.9, connected that to the outside interface of the pix, and ... nothing. The problem was that the"outside" computer couldn't route packets to the pix, because the outside interface of the pix is on a different subnet. I tried to tell it the route to the pix, with

route add -net 0/0 gw a.b.c.d eth0 (where a.b.c.d is the outside interface of the pix)

but it wouldn't accept that. After some googling, I tried:

route add a.b.c.d/32 dev eth0

route add -net 0/0 gw a.b.c.d eth0

And that worked! So now, packets from the "outside" computer intended for my inside network, were at least getting to the pix ... which was dropping them. I'll sort that out, though.

Another thing I discovered. If you're using the ASDM from one computer and try to use it from another, it doesn't work and you get a very misleading error message. After a while, I realised that it was probably too optimistic to expect this to work, closed one of them down, and now it works from my new Data Center workstation.  So now I can:

- reconfigure the "outside" computer (which I can only do sitting in front of it, because it's on this phony IP address)

- reconfigure the pix using the lovely web-based ASDM on the Inspirion

- see the pix error messages via the pix's serial port, connected to another computer that I log into and run a comms program (minicom) from the Inspirion.

Error messages are sometimes very misleading. If you think about this from the point of view of the programmer, he can detect that something isn't working, but once things aren't working right, it can be difficult, or even impossible, to say what's wrong. So you shold treat all error messages as meaning "Something is wrong, I don't know what" and regard anything more specific as potentially useful, but also potentially misleading.